🚀 go-pugleaf

The Windows API functions FindFirstFile and FindNextFile find files and
return information about them in a WIN32_FIND_DATA structure which along
with many other things contains the last write time.  Directories are just
files and the functions work for them.  Don't forget to call FindClose when
you are done with the search.

Depending upon which version of Windows and what file system is on the disk
the last modification time and date can be approximate, nearly exact or not
given at all.  Don't expect much if using Win95.

.  Ed

> Jarkko Juntunen wrote in message
> news:Xns9347BC315BB75dzeidzei@207.105.83.65...
>
> Need a way to get timestamp (last modification time) of
> a directory. Can  anyone help?

"Ed Mulroy [TeamB]" <ed@mulroy.org> wrote in message
news:3e7de3b8@newsgroups.borland.com...
> The Windows API functions FindFirstFile and FindNextFile find files and
> return information about them in a WIN32_FIND_DATA structure which along
> with many other things contains the last write time.  Directories are just
> files and the functions work for them.  Don't forget to call FindClose
when
> you are done with the search.
>
> Depending upon which version of Windows and what file system is on the
disk
> the last modification time and date can be approximate, nearly exact or
not
> given at all.  Don't expect much if using Win95.
>
> .  Ed
>
> > Jarkko Juntunen wrote in message
> > news:Xns9347BC315BB75dzeidzei@207.105.83.65...
> >
> > Need a way to get timestamp (last modification time) of
> > a directory. Can  anyone help?
>
>

Hi Ed,
I agree, FindFirstFile etc is the way to go, but there may be
some special cases.
For instance, if you try FindFirstFile with the name of a root
directory of a drive as the path parameter, the fuction fails
(i.e it returns INVALID_HANDLE_VALUE).
I tried this with "C:\\" and "C:", both returned
INVALID_HANDLE_VALUE.
Do you know of a workaround for this Ed?
Maybe there isn't one, in which case the prog would have
to test the directory name at "input level" to test for this
case.
Maybe it's because the root diretory of a drive is "intrinsic"
or "implied"?

Also the OP specifically used the term "directory" instead
of "folder" but if one wants to deal with the windows
concept of "folders" maybe there is another special case\
complication\problem, specifically "special folders?".
For example "My Documents" passed to FindFirstFile
as the path name results in failure. As you probably know,
if you create several "user profiles" under windows, then
the "My Documents" folder can map to a different directory
depending on the current user.
If no user profiles are used the default "C:\\My Documents"
works OK as it is a directory name as opposed to a folder
name.
I thought maybe there was a shell function that could retieve
the "last modification time" of a folder to cope with the above
cases but I couldn't find one.
Maybe I'm missing something.
Do you know of a shell function which does this?

Also, do you know if the "last modification time" of a directory
(e.g WIN32_FIND_DATA::ftLastWriteTime) is updated in these
circumstances:
  1. A file in that directory is updated.
  2. A new file is created in that directory.
  3. A file is deleted from that directory.
  4. A subdirectory is added to that directory.
  5. A subdirectory is deleted from that directory.
  6. A file is updated\created in a subdiretory of that directory etc.

To the OP, is this the sort of information you need to be
reflected in the "last modification time" of a directory?

TIA,
Dave

"David Cameron" <dave@NO_SPAM.please.ecclehill.freeserve.co.uk> wrote in
message news:3e7e0c97@newsgroups.borland.com...

> For instance, if you try FindFirstFile with the name of
> a root directory of a drive as the path parameter, the
> fuction fails (i.e it returns INVALID_HANDLE_VALUE).
> I tried this with "C:\\" and "C:", both returned
> INVALID_HANDLE_VALUE.
> Do you know of a workaround for this Ed?

Under NT/2K/XP, at least, you should be able to use CreateFile() to open the
drive directly and then use GetFileTime() or GetFileInformationByHandle().
Under Win9x/Me, you can't open a rive directly, but instead query it
indirectly using VMM32.VXD.

> For example "My Documents" passed to FindFirstFile
> as the path name results in failure. As you probably know,
> if you create several "user profiles" under windows, then
> the "My Documents" folder can map to a different directory
> depending on the current user.
> If no user profiles are used the default "C:\\My Documents"
> works OK as it is a directory name as opposed to a folder
> name.

You can use SHGetSpecialFolderLocation() and SHGetPathFromIDList() to
resolve a "special" folder name into its physical user-specific location,
and then use FindFirstFile() with that path instead.

> Also, do you know if the "last modification time" of a directory
> (e.g WIN32_FIND_DATA::ftLastWriteTime) is updated in
> these circumstances:
>   1. A file in that directory is updated.
>   2. A new file is created in that directory.
>   3. A file is deleted from that directory.
>   4. A subdirectory is added to that directory.
>   5. A subdirectory is deleted from that directory.
>   6. A file is updated\created in a subdiretory of that directory etc.

According to MSDN:

    ftLastWriteTime
    A FILETIME structure. For a file, the structure specifies when the file
was last written to. For a directory, the structure specifies when the
directory was created. If the underlying file system does not support last
write time, this member is zero.


Gambit

To get OP information, you're either going to have to go to the OP docs and
sources or ask someone who does a lot with OP.  This is the native API
group.  In this group if OP does anything useful then "that's ok too".

As for the root, No workaround is necessary.  The root is not a directory,
never has been.  If you are searching in the root directory the file times
and dates for its contents will tell you the last modification date.

On my machines (95 and XP Pro) and my wife's machine (98 SE) "My Documents"
is a perfectly good directory and shows when you do a directory search.
Under the Win 2K, XP types of Windows My Documents is a directory in the
user's directory tree.  Under 95/98/98SE it seems to be the same for
everyone.  On my machine it is:
  "C:\Documents and Settings\Administrator\My Documents"
or, if you prefer short names:
  C:\DOCUME~1\ADMINI~1\MYDOCU~1
but short names are not unique, especially across systems, so it is better
to use the long versions.

I don't know offhand of a Shell command that retrives the modification date
for anything related to directories.  Since Windows is MS' product, you
might try looking on their MSDN page.
  http://msdn.microsoft.com/library/default.asp

.  Ed

> David Cameron wrote in message
> news:3e7e0c97@newsgroups.borland.com...
>
> --bunch of stuff about modification dates related
>   to the root directory and object pascal--

"Ed Mulroy [TeamB]" <ed@mulroy.org> wrote in message
news:3e7e4381@newsgroups.borland.com...
> To get OP information, you're either going to have to go to the OP docs
and
> sources or ask someone who does a lot with OP.  This is the native API
> group.  In this group if OP does anything useful then "that's ok too".
>

Sorry, maybe I wasn't clear, I was using OP as meaning Original Poster.

> As for the root, No workaround is necessary.  The root is not a directory,
> never has been.  If you are searching in the root directory the file times
> and dates for its contents will tell you the last modification date.
>
> On my machines (95 and XP Pro) and my wife's machine (98 SE) "My
Documents"
> is a perfectly good directory and shows when you do a directory search.

Yes "My Documents" is a valid directory on my system (98 SE) but when
used as the lpFileName parameter to FindFirstFile, the function fails
(returns INVALID_HANDLE_VALUE).
"My Documents" fails.
"C:\\My Documents" suceeds.

> Under the Win 2K, XP types of Windows My Documents is a directory in the
> user's directory tree.  Under 95/98/98SE it seems to be the same for
> everyone.  On my machine it is:
>   "C:\Documents and Settings\Administrator\My Documents"
> or, if you prefer short names:
>   C:\DOCUME~1\ADMINI~1\MYDOCU~1
> but short names are not unique, especially across systems, so it is better
> to use the long versions.
>

Did you ever use different "user profiles" under 98SE Ed?
 I'm pretty sure the "My Documents" special folder, and others
map to different actual disk directories depending on the current
user.

> > David Cameron wrote in message
> > news:3e7e0c97@newsgroups.borland.com...
> >
> > --bunch of stuff about modification dates related
> >   to the root directory and object pascal--

C++ actually, sorry it was the OP thing :o

Thanks,
Dave

"Remy Lebeau (TeamB)" <gambit47@yahoo.com> wrote in message
news:3e7e23e6$1@newsgroups.borland.com...
>

[snipped advice]

Thanks Gambit,
Dave

Ed Mulroy wrote:

> To get OP information, you're either going to have to go to the OP docs
> and sources or ask someone who does a lot with OP.  This is the native
> API group.  In this group if OP does anything useful then "that's ok too".

I believe that's OP as in "Original Poster."
OP-- it's not just "Object Pascal" anymore ;)

"David Cameron" <dave@NO_SPAM.please.ecclehill.freeserve.co.uk> wrote in
message news:3e7e4f67$1@newsgroups.borland.com...

> Yes "My Documents" is a valid directory on my system (98 SE)
> but when used as the lpFileName parameter to FindFirstFile, the
> function fails (returns INVALID_HANDLE_VALUE).
> "My Documents" fails.

As well it should, as "My Documents" on its own is not a valid folder name.
FindFirstFile() requires a actual physical path.  Refer to my other reply
for more details.


Gambit