[Q] How to determine the order that files were put into a folder??
kleefaj
Does anyone know of a reliable way to determine the order that files
were copied/moved into a folder? That is, I want another program to
work on the first file copied into a folder, then the next, etc.
The DateLastAccessed property of the File object appears to work but
if the user opens the file before processing by the other program then
the DateLastAccessed property changes.
Any ideas?
Thanks,
Jeff
Karl E. Peterson
Take a look at DateCreated. If that doesn't work, you're probably hosed.
--
.NET: It's About Trust!
http://vfred.mvps.org
Paul Randall
"kleefaj" <kle...@gmail.com> wrote in message
news:1176835275....@b75g2000hsg.googlegroups.com...
Hopefully someone else will jump in with a better answer. My answer is
based on things I saw using Norton Commander for DOS, back in the early
1990's.
If the folder has just been created, and no files have been deleted, then
the order seen when you do a DOS DIR command should show you the unsorted
order. Perhaps, using script, the enumeration of file objects in a File
System Folder object's files collection (oFolder.Files) will be the order
they were created in the folder. When you delete a file, the space for that
directory entry becomes available for a newly created file. I think that
this might mess up the order you are interested in.
-Paul Randall
MikeD
There's not really any way to know or determine this with absolute
certainty. It even depends on the file system (for example, FAT32 vs. NTFS).
Karl's recommendation of using the create date is probably the best you can
hope for.
Also, not really a good idea to crosspost to VB scripting and VB newsgroups.
There are enough differences between VB and VBScript that answers you get
may not be applicable.
--
Mike
Microsoft Visual Basic MVP
kleefaj
> Also, not really a good idea to crosspost to VB scripting and VB newsgroups.
> There are enough differences between VB and VBScript that answers you get
> may not be applicable.
>
> --
> Mike
> Microsoft Visual Basic MVP
I figure since the FileSystemObject class may come into play then the
VBScript and VB newsgroups would be appropriate.
I've decided to create a queue in memory and continue polling the
directory to see if anything's been added. If there are new files I
add them into the queue.
Thanks,
Jeff
Bob Butler
> <snip>
>> Also, not really a good idea to crosspost to VB scripting and VB
>> newsgroups.
>> There are enough differences between VB and VBScript that answers you get
>> may not be applicable.
>>
>> --
>> Mike
>> Microsoft Visual Basic MVP
>
> I figure since the FileSystemObject class may come into play then the
> VBScript and VB newsgroups would be appropriate.
The FSO wouldn't come into play at all from VB, except as a kludge
kleefaj
> > I figure since the FileSystemObject class may come into play then the
> > VBScript and VB newsgroups would be appropriate.
>
> The FSO wouldn't come into play at all from VB, except as a kludge
I disagree. Other than using the API what better way is there for
interacting with the operating system? FSO makes it really easy!
-Jeff
MikeD
*Easier* maybe, but not good. You're not going to find hardly anyone that
will agree with you on this. Those that do are going to be the hobbiest
programmers, not those that do programming for a living.
VB has file I/O capabities so the FSO is never needed. On some systems the
FSO might be disabled or even completely removed for security reasons.
There are so many versions of it that it can also cause compatibility
problems. It's slow and bloated.
Basically, there are no *good* reasons whatsoever to use it in a VB app.
If you want "easy", meaning an object for file I/O, write your own class.
Lee Peedin
>I've decided to create a queue in memory and continue polling the
>directory to see if anything's been added. If there are new files I
>add them into the queue.
>
>Thanks,
>Jeff
Or you might consider letting WMI monitor the folder for you.
<http://www.microsoft.com/technet/scriptcenter/resources/qanda/feb07/hey0214.mspx>
Lee
Mike Williams
news:uK35xDpg...@TK2MSFTNGP04.phx.gbl...
> *Easier* maybe, but not good. You're not going to find hardly
> anyone that will agree with you on this. Those that do are going
> to be the hobbiest programmers, not those that do programming
> for a living.
I'm a hobbyist and I definitely do NOT agree with him! The FSO is an
abomination!
Mike
Alexander Mueller
> If the folder has just been created, and no files have been deleted, then
> the order seen when you do a DOS DIR command should show you the unsorted
> order. Perhaps, using script, the enumeration of file objects in a File
> System Folder object's files collection (oFolder.Files) will be the order
> they were created in the folder. When you delete a file, the space for that
> directory entry becomes available for a newly created file. I think that
> this might mess up the order you are interested in.
This is true for FAT, but not NTFS.
MfG,
Alex
Karl E. Peterson
ANY(!) way is better. There is no more dispute there, than there is on climate
change or evolution. Only the ignorant (no offense -- it's a curable disease!)
argue for any of those.
Save FSO for situations where (ANY!) other solutions don't apply, like VBScript.
> FSO makes it really easy!
Ignorance is Bliss. ;-)
Robert Morley
slow, and adding a lot of unnecessary overhead to file operations that can
mostly be done either directly in VB (possibly by creating your own FSO
equivalent, if you're so inclined), through the API if you're knowledgeable
enough, or through other means (like third-party controls/libraries) if all
else fails.
I *think* you can do most of the same things in VB as you can through FSO
(albeit with a lot more coding involved for many VB-only solutions), but I
don't profess intimate knowledge of FSO, so there may be a few things you
can only do through other means.
That said, if you're content with the speed it runs at, and don't need to
use it for anything heavy-duty, if it works for you, go for it. In most
situations, you're better off doing just about anything you can to avoid it,
though.
Rob
"Karl E. Peterson" <ka...@mvps.org> wrote in message
news:uDt4sgqg...@TK2MSFTNGP02.phx.gbl...
Rick Raisley
> <snip>
>
>
> I disagree. Other than using the API what better way is there for
> interacting with the operating system? FSO makes it really easy!
>
I'm not saying it's a great method, but I've used DOS batch files to obtain
directories of files, written to a file, and then imported that into VB.
I've actually used them quite successfully for the normal DOS ease of
recursing directories, wildcards, parameters, etc.
--
Regards,
Rick Raisley
Chris Dunaway
>
> If you want "easy", meaning an object for file I/O, write your own class.
>
If anyone is interested, there is a replacement for the FSO here that
looks pretty good:
http://killervb.com/FileSystemLib.aspx
Chris
Steve
I am not sure if this will work or not, but it seems like it may so
here ya go. In another thread in another group (here
http://groups.google.com/group/microsoft.public.vb.winapi/msg/cf3cdca00caad080?hl=en&)
Tony Procter suggested using the file index (which is held in the file
info structure) to uniquely identify a file. I imagine that this
index is simply a sequentially generated number and could therefore be
used to determine the relative age of two files...the smaller index
number is the older file. If this is infact true then it would not be
too difficult to extend the logic to determine the order of files in
an entire directory.
Hope this helps,
Steve