File CreationTime mystery

[Gösta H. Lovgren-2]

Seems some other readers are getting a bit testy... I'll post the "answer" tomorrow...

Not to sound testy but today is tomorrow (at least according to my TimeStamp).

=======================================================
"Everyone is a genius at least once a year;
a real genius has his original ideas closer together."
Georg Lichtenberg (1742-1799)
=======================================================

[Roger Garstang]

And, if you really want messed up, try DST and Timezone file time shifts. Your times show different on NTFS depending on the time of year, timezone, if it was on CD or within a zip during a shift, etc.

[Roger Garstang]

People tend to forget when a file is deleted it isn't really gone...at least until data is wrote to where it was. Back in Norton Disk Doctor days...when it was good (Before Symantec)...I used to even know the character that gets wrote over the first digit of the name and could hide files by naming them with that so DIR didn't list them, but they were still there and wouldn't get wrote over like the deleted files did. That is why in early DOS you were made to type a char in during Undelete. You can still Undelete in Windows too which is much better than the useless Recycle bin. Norton had a Protected trash that was still not the same too. Apparently though you can copyright a name such as Undelete, so places like SysInternals have to rename their version to Fundelete.

[Michael Mattias]

>and I DO do it myself, and the change DOES NOT HAPPEN as intended.

Failing code not shown.

[John Montenigro]

My bet would be in the FAT table (No longer the right term, I know but you know what I mean). When files get deleted (normally) a flag just gets set in the FAT that makes the fie invisible (again you know what I mean). The file really doesn't go anywhere. Just makes the space available to write over.

I do know what you mean, and you're close, but it does not have anything to do with the FAT or with the file being "still there but invisible." Initially, this was my suspicion, too.

Probably when REcopying the flag gets (un)set restoring (some) values instead of overwriting them.

Very close but not what you think!

Oh, and John, just for the record, I care. {laughing}

Thanks for your support Gosta!

Seems some other readers are getting a bit testy... I'll post the "answer" tomorrow...

[John Montenigro]

>X was retained SOMEWHERE! WHERE? HOW? What is the mechanism?

Who the hell cares?

If you want file timestamps retained/modified after a copy just do it yourself and be done with it!

Or, have a stroke.

"Who the hell cares?" WOW. Michael I am disappointed in your total density on this.


You are SO missing the point. (Besides being in a foul mood - which is no excuse for the "have a stroke" remark, for which you've lost a lot of respect from me.)


Yes, I want the "file timestamps retained/modified after a copy", and I DO do it myself, and the change DOES NOT HAPPEN as intended.

Why don't you "just do it yourself" and observe the result? The re-copied file DOES NOT ACCEPT the date change, and there is NO INDICATION of failure. Instead, the newly copied/renamed file is given the same date that had been on the DELETED FILE. Get it?
.
.

Re-stamping the newly re-copied file results in its getting the stamp of the OLD, DELETED file.

This is OK with you? Of all people, I'd have thought you'd get the significance of this TOTALLY ILLOGICAL scenario.

[Gösta H. Lovgren-2]

SO then why are we seeing X ?

X was retained SOMEWHERE! WHERE? HOW? What is the mechanism?

My bet would be in the FAT table (No longer the right term, I know but you know what I mean). When files get deleted (normally) a flag just gets set in the FAT that makes the fie invisible (again you know what I mean). The file really doesn't go anywhere. Just makes the space available to write over.

Probably when REcopying the flag gets (un)set restoring (some) values instead of overwriting them.

Oh, and John, just for the record, I care. {laughing}

=====================================
Who has a harder fight than he
who is striving to overcome himself.
Thomas a Kempis
=====================================

{Later}From Wikipedia:
NTFS is the standard file system of Windows NT, including its later versions Windows 2000, Windows XP, Windows Server 2003, Windows Server 2008, and Windows Vista.[4]
NTFS supersedes the FAT file system as the preferred file system for Microsoft’s “Windows”-branded operating systems. NTFS has several improvements over FAT and HPFS (High Performance File System) such as improved support for metadata and the use of advanced data structures to improve performance, reliability, and disk space utilization, plus additional extensions such as security access control lists (ACL) and file system journaling. The file system specification is a trade secret,[5][6][7] although it can be licensed commercially from Microsoft through their Intellectual Property licensing program.[8][9]

[Michael Mattias]

>X was retained SOMEWHERE! WHERE? HOW? What is the mechanism?

Who the hell cares?

If you want file timestamps retained/modified after a copy just do it yourself and be done with it!

Or, have a stroke.

[John Montenigro]

OK, source file A in subdir A has a CreationTime of "A"
we FileCopy it to B, and its CreationTime automatically gets set to the current date/time. It no longer has a CreationTime of A; that's now gone.

On the COPY we change the CreationTime to X.

Now we DELETE the COPY - and say good-bye to the file, the only place where X was ever set.

Now we copy the source file A again to B. We expect to see the current date/time, right?

SO then why are we seeing X ?

X was retained SOMEWHERE! WHERE? HOW? What is the mechanism?

[Adam J. Drake]

I've never paid too much attention to how file date/time stamps work during a copy - so I'm not too sure what is or isn't strange.

[John Montenigro]

Michael, Adam,

Did you try the steps I outlined and NOT see anything strange?

Did you change the Creation Date of a copied file, DELETE IT, re-copy from the original, and then check the Creation Date of the post-delete copy?

[Adam J. Drake]

John,

Are you moving or copying a file?

If moving - not copying - you can use the NAME command to move a file.

If copying - then you would need to use what Michael suggested and ensure FileTime is preserved yourself.

EDIT: Scratch that suggestion - apparently moving by using the NAME command also resets the creation date/time stamp. You will need to ensure file date/time stamps are preserved on your own if you are going to depend on them...

[Michael Mattias]

]
SetFileTime

The SetFileTime function sets the date and time that a file was created, last accessed, or last modified.

BOOL SetFileTime(
  HANDLE hFile,
  const FILETIME* lpCreationTime,
  const FILETIME* lpLastAccessTime,
  const FILETIME* lpLastWriteTime
);

MCM

[John Montenigro]

As mentioned above, yes, MS did not have clear standards when they went moved away from the FAT system. The uses of the three dates that became available were not well defined, and in fact various commands do counter-intuitive things that make them fairly useless. Only LastWrite seems to be consistent.

And yes, when a file is copied, an existing file of that name in that destination gets overwritten, and it does NOT inherit the Creation Date of the original. As Adam mentioned, the copy's Creation Date gets set to the current date/time.

So you cannot rely upon a file's Creation Date once you copy or move it, even if you're not making any changes to it. In the narrow context that the copy is a "new" file, it's logical. But in the larger context of the user, the file wasn't changed, only its location. How does simply relocating a file justify the loss of the record-keeping capability afforded by the original Creation Date?

In any case, for my purposes, if one of my apps has to move a file, I want to preserve the Creation Date of the original. Fine, that's my own rule.

HOWEVER, the anomoly shows up when you have changed the date on a file, you DELETE it later, AND THEN re-copy the same original to that same destination. If the rules were consistent, you'd see the current date/time on the new copy.

BUT YOU DONT!!!

On the NEW copy, made AFTER the first copy was DELETED, you see the CHANGED DATE that you put on the FIRST copy!!!

To me that's just too weird... but at least now I know WHY...

[Conrad Hoffman]

Fine if you're getting your own file info, but Microsoft and other applications are not consistent in how they handle the date.

[Michael Mattias]

>and file dates have been close to useless ever since.

???

"Last write" is handy.

[Conrad Hoffman]

In the dim dark days of DOS a file got its creation date when it was written. It kept that date until it was overwritten. The date was a useful feature that could be used to tell when things were created. At some point under Windows, Microsoft "fixed" that behavior, and file dates have been close to useless ever since.

[Michael Mattias]

Depends.. I've observed if the file already existed in the target folder it uses the creation date of that file as it exists...and if it didn't it uses current date-time.

But there's probably some deep dark user option which no one will ever find which actually controls this behavior.

But to get back on topic... what about the creation date? How/why is that used in the application? Maybe there is another way to go about doing whatever it is needs doing.

MCM

[Adam J. Drake]

Is it not normal behavior for a file copy to set the creation date of the destination file to the current date/time stamp?

[Michael Mattias]

As Rhett said to Scarlett.....