FileSystemObject Woes--It finds non-existent files. 1

[jsteph]

Hi All,
I am using the FileSystemObject to load a table with files from my harddrive.

When I use the following
.NewSearch
.LookIn = "E:\ '(also tried E:\)
.SearchSubFolders = True
.FileType = 1 'msoFileTypeAllFiles=1
.FileName = ".mdb"
.Execute

...At this point I list the files, do a .FileLen and .FileDatetime on each one, then load that info to a table.

The (extremely) odd and frustrating thing is--it puts a "C:\" on subfolders that also exist in E:\, for example, I had changed HD's a while back and my E: drive has a "Program Files" folder. It's contents are much different, and FileSystemObject will show a:

"C:\Program Files\SomeOldApp\Some.mdb"
..which does not exist, but:
"E:\Program Files\SomeOldApp\Some.mdb" Does exist!

To compound this, it also shows files, such as
C:\JimTest\TestFolder\Test.mdb
Which does not exist anywhere!

As I wrote this, and before I posted, I think I found the answer--but still a question:
How do I tell FileSystemObject that dead shortcuts in the Recent File List are NOT REAL FILES!!!. Is that an option with FileSystemObject?
jsteph

 

[willir]

A file is a file. Even a directory is a file (containing a list of files).

At the OS level, when you display a directory, you are actually just displaying the contents of the directory file.

The way Windows handles shortcuts is sometimes kind of wierd -- it sometimes results in depicting files in other directories. I saw this just last night on my home PC.

Perhaps a work around solution would be to filter the data afterwards. For example, drop or delete or ignore c:\ records.

Richard

 

[jsteph]

willir,
Thanks...that's what I'll be doing. And the search object does indeed extract the Properties|Shortcut|Target property of the .lnk file--that's the annoying part:
To me, a file with the name "something.lnk" is a file. Period. Just because it contains, somewhere in that file, the name of another file is not something that the search object should care about, in my opinion. But my opinion and that of Bill Gates differ. And look who's got more money.

What I'm doing in the loop of .FoundFiles is simply attempting a FileDateTime on the file--if it fails, it's a dead shortcut. If the 'real' file is already in my destination table, then any dups (from multiple Recent entries) are ignored.
--jsteph

 

[willir]

jsteph

With the move to Win 95 and NTFS platforms, I feel Windows has tried to emulate Unix, except in a graphical environment.

The difference is that Unix, in my opinion, has a far richer scripting environment that is part of the native OS. In this case a "grep -v" could have been used to filter out the link. (And Unix did it 10 years earlier.)

I love your solution for testing a date-stamp. I am going to give you a star for your orignality.

Richard

 

[jsteph]

willir,
Thanks!
--jsteph

 

[DaltonVB]

I know the solution has been found but...

Couldn't you check to see if the fiel exists before you do something with it?

Set oFS = CreateObject("Scripting.FileSystemObject")
    f_FileExists = oFS.FileExists(szFileSpec)

 

[jsteph]

Dalton,
Read my second-to-last post, I'm doing something similar, but with less overhead than creating a FileSystemobject.
--jsteph

 

[DaltonVB]

cool. thanks