blog: file date anecdotes

[nikos]

here's the comment area for today's blog article found at
http://zabkat.com/blog/26Jun11-creation-date-memory.htm

[fgagnon]

I've run into the creation date with memory curiosity more than once and have been baffled as to *why*?  Thanks for the info.

But for a folder with hundreds of other files, do you know of a way to reuse a filename and have the creation date reflect that of the new one without messing up the creation and access dates of the other files (such as by moving the lot to a new folder)?

[nikos]

sometimes creation date is naturally reset. I don't know when or how, but if you do the delete-recreate cycle a few times then sooner or later the creation date will reset to the present

of course in x2 just use <ctrl+F12> as such

[RightPaddock]

delete the file you don't want - e.g. myavatar.gif

create a scrap file - e.g. x2scrap.txt

create the new instance of the file you want - i.e. myavatar.gif, with the appropriate program - MSPaint.exe

the new myavatar.gif's creation date should have current date & time

trash x2scrap.txt

[nikos]

not quite! but there is one way to reset the creation date which one day we will find out

[fgagnon]

of course in x2 just use <ctrl+F12> as such

sadly I forgot that creation date is p/o that dialogbox choice (which I use regularly for adjusting modification date).

So now I will try and remember to use it for adjusting creation, too ... at least from now until the rapture.

[Robert2]

Actually, it is SHIFT+F12

[John_Gray]

This technical article about Windows File Dates and Times from eleven years' ago is still worth reading.  (Basically, it says that File Created and File Access times are misleading and a complete waste of space, with only File Modified/Charged times being meaningful.)

A pedantic point is that Windows displays NTFS file times to the nearest second (unless you're using Samba, when it's two seconds!), but the times are held in the file system to a precision of 100 nanoseconds.

[quietbritishjim]

Hope it's OK to bump this old thread, but I have a bit of extra info.  [edit]Actually it's not old at all. I misread the date as 2010![/edit]

Creation date "memory": In many programs, if you modify a document then save it, then instead of just writing to the file the program will write to a new copy, delete the old one and move the new one over. Windows' behaviour ensures that this looks seamless to the user, who doesn't consider this to be a new file. It's called "file system tunneling" and is explained in this post in Raymond Chen's excellent blog The Old New Thing (essential reading for all Windows programmers).

By the way, if you follow through the link above you'll find that the time window for this is 15 seconds (this is not official documentation so might have changed, but it also tells you where to find the true value). This is eons for a computer, but quite short for a human being, so if you do this enough times then eventually you'll take "too long" and succeed in updating the creation date.

Last accessed time: As of Windows Vista, this is no longer updated unless you specifically enable it. See this blog post, which I also found via an Old New Thing post.

[nikos]

I just remembered how MFC saves files which may seem callous at first, it is effectively ensuring a new creation time. However it creates more problems than it solves!

[quietbritishjim]

Does it really update the creation time? It's exactly the operation that tunneling is meant to apply to.

The reason for writing files that way is not to update the creation time, but to avoid the possibility that a crash (in the program or the whole computer) will cause the file to be half written with the new contents, with half the old contents left behind. Depending on the file type, this could make the file completely unusable. With the write to new/delete/rename operation the worst case scenario is that you're left with the old file (or just the new one in the wrong location, if the crash is just after the delete), but you're guaranteed to have a working file.

How do you combine this robustness with preservation of hardlinks and streams? I'm not sure what the "correct" solution is, but one idea is to write the file directly, but copy to a backup file just before writing to it (and deleting the backup when done, perhaps optionally).

[quietbritishjim]

I'm not sure what the "correct" solution is...

Yes I do, I was just having a brain lapse! As of Windows Vista the correct solution is transactional NTFS.

In short, NTFS is a journalling file system. This means that Windows doesn't have the same problem as users: even if Windows blue screens during a file copy, either the copy completes or totally fails, never leaving partially copied file behind. Transactional NTFS lets applications take advantage of this journalling, so that your complex update to a file can be atomic too. Transactions can even cover multiple files.

[edit]Fixed a wrong example; I suggested the OS implemented moves within a drive as copy + delete, when it presumably just updates where the file is linked from. (Although this still requires a transaction to ensure it's not linked from two locations if there's a crash part way through the operation. Especially since the link count would be 1!)[/edit]