forum.vdsworld.com

[vtol]

The packed binary value returned by the @FILE(name,T) pseudo-attribute converted to a normal date/time format using the @DATETIME function returns the ACCESSED TODAY.

I just need the MODIFIED DATE is all.

Does anyone know how to run it through the BIN to get the Modified DATE, its prolly just a HEX conversion.

Thanks for looking

[DaveR]

I believe the file dates/times aren't in the file itself but stored in the partition's file table.

[vdsalchemist]

vtol,
I think Dave is correct, however with GadgetX you could use the @GetFile(DATETIME) which will return the last modified datetime stamp that you can give to the VDS @DateTime function.

[vtol]

IC
So that would be interesting on like a burned CD format.

I know, the @file(name,T) gives a binary number, but when converted with @datetime() it turns out to be the Last accessed number.

I need the MODIFIED Date(compile date).

But are you saying that if you reformat your partition and move it from CD and back and forth it could you could loose the oringinal compile date?

Can I try Gadget as demo? (I'm broke as usual right now).

Thanks

[DaveR]

Usually when you copy or move a file the operating system copies the original created and modified date/time. Most FTP programs have an option to retain the original file's date/times.

[vtol]

IC

I guess that explains why its so easy to get the real file date with a server command.

When you say Partition Table, are you referring to the one in DOS that you can pass the /MBR parameter to with Fdisk? I was thinking that(HD table) would stay a tiny CMOS writible area.

But maybe you meant Windows writes it own version of that table as a massive second copy.

Interesting...

[vdsalchemist]

[jules]

I always thought @file(name,T) returned the file time stamp (i.e. date written or modified.) VDS uses the Delphi file access routines not the Windows API so it returns the value in TSearchRec.Time.

[vdsalchemist]

[vtol]

Thanks
Well I think I confused everyone to start

First I've allways noticed every since I started using Windows XP that I disliked the Properties simply because about 60% of the time the Modified date would be older than the Creation date.
So so for years I've been wrong and using the Modified date as the REAL Creation date.
After vigorous testing the last few days (in Windows2000pro) I found that the VDS @file,T + @datetime gave the TRUE Creation date everytime, or at least the oldest date of the three which I also been calling the Compiled date.
So I will be testing this on Windows XP and Windows 98se in the next few weeks, since my program will allways use VDS filedate as long as it keeps working as it did in Windows 2000 Professional.

I was real happy to find out VDS was as good or better than DOS DIR and a few downloaded Filedate getters utilitys.

Thanks for helping me on this very much

[vdsalchemist]

vtol,
My experience with Windows XP is that the @file(name,T) returns the datetime stamp of when the file was last modified. With the exception of a new file this datetime stamp should always be newer than the created date. On new files the created date and Modified date should be the same date.

[vtol]

I wish my XP worked like that or that good

My problem is the Creation Date is a few years newer than the Modified Date a lot of the time, so that leads me believe something is wrong somewhere.

And I've never intentionally messed with file dates that I'm aware of.

Maybe I eat too many Cayennes and Jalapenos in the summer.

Well maybe in XP I will get the same result you get, that would save my sanity at least.

[Hooligan]

Here's an interesting artical that ought to throw a wrench in your works...

http://msdn2.microsoft.com/en-us/library/ms724290.aspx

Hooligan

[vdsalchemist]

[vdsalchemist]