Return File Modified/Create Date

[AP]

Is there anyway to determine what the modified or create date is for a
file? In my example I am uploading a text file using the following to
select the filename: GetOpenFileName Lib "COMDLG32.DLL". Is there
anyway to point to that file and return the information about the file
properties? Size, date modified, created, etc?

Thanks

[Chuck Grimsby]

Yeah, you can get at all the file date/time info via the GetFileTime()
API call, but do you really care if the date modified and the date
created don't match?

The size and date modified are available via the FileLen and
FileDateTime functions built into Access. If those will work for you,
go for it!

If you really do need to know the date created, Last Accessed, and Last
Changed values, then the GetFileTime() API call is what you need to
use. Unless, of course, you're doing a search, since that information
comes back as a part of the FindFirstFile() and FindNextFile() API
calls.

[LeighP]

I've used the unsurprisingly named GetFileTime and GetFileSize API functions
for this in the past - but have found them to be not utterly reliable -
particularly across network drives.
Anyone else found this?

"AP" <ap******@thompsongroup.com> wrote in message
news:11**********************@g49g2000cwa.googlegr oups.com...

Is there anyway to determine what the modified or create date is for a
file? In my example I am uploading a text file using the following to
select the filename: GetOpenFileName Lib "COMDLG32.DLL". Is there
anyway to point to that file and return the information about the file
properties? Size, date modified, created, etc?

Thanks

[Trevor Best]

Chuck Grimsby wrote:

but do you really care if the date modified and the date
created don't match?

A lot of the time they won't, in fact the most likley scenario is that
modified is earlier than created date. This is because the create date
will be the date it's copied to your PC while the modified date is
maintained from the original. Unless of course you downloaded the file
from the web or FTP in which case the created date will be the start of
the download and the modified date will be the end of the download so
the only information on dates/times you can gleen from downloaded files
is the time it took to download them and when :-)

This is another reason for zipping files, the files inside the zip file
maintain their modified date, so if you ever wondered why people bother
zipping files that don't compress very well...

--
[OO=00=OO]

[Chuck Grimsby]

I can't say I've ever had "major" problems with the GetFileSize API
call. To be honest, I don't use it a lot though. FileLen is just too
blazingly easy to use! <Grin>

Like you, I have had some problems on some networks with GetFileTime
however. I remember something or another about a 1601 date on
Non-Windows networks (or networked drives) and whether or not a Windows
PC created or last accessed the file. I'm guessing here since I'm not
sure where my notes are on this, but as I recall, the trick was to get
the Last Modified date first, and ignore the dates that were really
bizare from that.
I think that 1601 date had something to do with a Unix or Linux file.
That was a while back however, so I'm not sure if that's still the case
or not.

[Chuck Grimsby]

See my reply to LeighP, which explains some of the weirdness I've seen.
On Windows PCs however, in addition to what you mentioned, I've also
discovered that the file date/times also have to do with the program
that "last accesses" the file. Some programs totally re-write the
file, others make modifications to the file. Think Access and NotePad
here. When you make a change to an Access file, it's modified. In
NotePad, the file saved is a complete new file. There are other
programs that do this as well.

On occasion it's a good idea to save a copy of a Word or Excel file as
a new file in a new location to "clean out" some of those program's
little extras that build up over time, and then copy the file to it's
oiginal location replacing the existing file. In such cases, even
though you "know" the file has been out there since 1998, it's a new
file, so the dates only appear to be weird.

[AP]

Thanks, the FileDateTime was exactly what I needed.

[Trevor Best]

Chuck Grimsby wrote:

I can't say I've ever had "major" problems with the GetFileSize API
call. To be honest, I don't use it a lot though. FileLen is just too
blazingly easy to use! <Grin>

FileLen returns a long int, useless on files >2GB :-(

--
[OO=00=OO]

[David Schofield]

On 7 Jun 2005 02:28:07 -0700, "Chuck Grimsby"
<c.*******@worldnet.att.net> wrote:

See my reply to LeighP, which explains some of the weirdness I've seen.
On Windows PCs however, in addition to what you mentioned, I've also
discovered that the file date/times also have to do with the program
that "last accesses" the file. Some programs totally re-write the
file, others make modifications to the file. Think Access and NotePad
here. When you make a change to an Access file, it's modified. In
NotePad, the file saved is a complete new file. There are other
programs that do this as well.

On occasion it's a good idea to save a copy of a Word or Excel file as
a new file in a new location to "clean out" some of those program's
little extras that build up over time, and then copy the file to it's
oiginal location replacing the existing file. In such cases, even
though you "know" the file has been out there since 1998, it's a new
file, so the dates only appear to be weird.

Hi
Also some of the times you get from the VB routines "flip" an hour
when daylight saving time comes and goes, this was a "feature" of NT
which confused a few file updating schedulers.
David

[Chuck Grimsby]

Indeed. As I mentioned before, I don't do a lot with that code
anymore. Back a few years I wrote a form that scans a volume or
directory and pumps the information into a table. I keep reusing that
form over and over again without having to change it, so I really don't
think about it a lot. If memory serves however, I have the variable
that holds the filesize decared as a Currency type, which kind of gives
you an idea of how old that code is! (Win 3.11 days.)