Topic: vlisp substitute for findfile

[laidbacklarry]

Findfile is inconsistent/undependable for files in \system32 (at least on Windows 7 64-bit). Is there a vlisp alternative?

Thanks for any help...

[Lee Mac]

?

Code: [Select]

(defun File-p ( filename / fso res ) (vl-load-com)
  (vl-catch-all-apply
    (function
      (lambda nil
        (setq fso (vlax-create-object "Scripting.FileSystemObject"))
        (setq res (not (zerop (vlax-invoke fso 'FileExists filename))))
      )
    )
  )
  (if fso (vlax-release-object fso))
  res
)

[laidbacklarry]

Thanks for the try Lee, but it didn't work. The problem appears to be the location, \System32. I can find the file with Winedit but not with Notepad. I can find it with UltraExplorer but not with Windows Explorer. Likewise with AgentRansack Search but not with Windows Search.

The file is a license manager file that keeps track of expiry date, date last used, etc., so \System32 seemed like a good choice to keep prying eyes away. And it's been successful until Windows 7 started being used. Guess I'll have to find another location.

Can't tell you how much I dislike M'soft. Whatever tactic Microsoft is using with \System32, it looks like Autodesk is going along with them.

[Lee Mac]

How are you specifying the filename? Are you using Double-Backslashes?

[laidbacklarry]

I've tried both ways. And for clarity, if I move the file to C:\Windows (or any other folder), both findfile and your routine work. But, strangest of all, if I open a DOS window in \System 32, not even DIR can find the file. It's a file that my Wise installer program creates during installation so there's nothing exotic about the file. I use a .DAT file extension even though it's actually an .INI file in structure. I've tried changing the file extension to both .INI and even .TXT. Nothing seems to work. But, thanks again for your effort.

[Lee Mac]

\System32 with no Drive? Maybe I'm being dumb, but I thought System32 was located in the Windows Folder.  :ugly:

[efernal]

suggestion:

Code: [Select]

(defun MFINDFILE (my_file my_extension)
  (findfile
    (strcat
      (getenv "WINDIR")
      "\\System32\\"
      my_file
      my_extension
    )
  )
)

Command: (mfindfile "c50032" ".dll")
nil

Command: (mfindfile "acad"".err")
"C:\\Windows\\System32\\acad.err"

Command: (mfindfile "wbem\\aaclient" ".mof")
"C:\\Windows\\System32\\wbem\\aaclient.mof"


[laidbacklarry]

Lee - Sorry, I was just using "shorthand" to name the folder. And Efernal - my code is essentially what you listed.

As I said, non-Microsoft File Selection dialogs include the desired filename in the file list, but Microsoft (Windows 7 64-bit) File Selection dialogs do not (and many other filenames are missing in the Microsoft dialogs as well).

And the DOS command DIR does not include the desired filename.
Nor does (setq fils (vl-directory-files win32_dir "*.dat" 0)) where win32_dir is C:\Windows\System32 on most systems.

While my curiosity is still up, I've decided to take the simple way out and relocate the file to the Windows folder.

[ElpanovEvgeniy]

my version

[Lee Mac]

I have this also, but I doubt it will be of much use since it uses findfile...

[laidbacklarry]

Elpanov - Thanks, but it didn't work either. Lee - Nope, vl-directory-files doesn't include the desired file in the returned list.

The filename does not show up in the Select File dialog for Windows Explorer, Notepad, Write, or Word. It does show up for Microsoft Works Word Processor but won't load. It shows up (and opens) in all non-Microsoft programs I tried including UltraEdit, UltraExplorer, Jarte, Notepad++, and Winedit.

When I first discovered the problem several months ago I changed my installation program to make a second copy of the file in one of my program folders. I have found that although I can use lisp to create a readable file in the System32 folder, vl-file-delete won't delete the original file.

Final solution is to use vl-file-copy to copy the second file to System32 with a different file extension and change a few lines of code. Still scratching my head over this though.

[VovKa]

there are two system32 in win64: one is for 64bit apps and another for 32bit apps.
Windows Explorer, Notepad, Write, are all 64bit but you saved your file using 32bit installer.
http://msdn.microsoft.com/en-us/library/aa384187(v=vs.85).aspx

[JohnK]

and to add to what VovKa said, the same things happens in the registry too.
http://www.theswamp.org/index.php?topic=31968.msg377798#msg377798

[laidbacklarry]

there are two system32 in win64: one is for 64bit apps and another for 32bit apps.
Windows Explorer, Notepad, Write, are all 64bit but you saved your file using 32bit installer.
http://msdn.microsoft.com/en-us/library/aa384187(v=vs.85).aspx

Thanks, the link helped explain what happened. But it seems to indicate that only DLLs are redirected. And even though the file is a simple ASCII text file, perhaps I shot myself in the foot by assigning a .DAT file extension to help it "blend into the background".

[JohnK]

<snip> But it seems to indicate that only DLLs are redirected. <snip>

No it didnt.