blog: file date anecdotes

Discussion & Support for xplorer² professional

Moderators: fgagnon, nikos, Site Mods

User avatar
nikos
Site Admin
Site Admin
Posts: 16295
Joined: 2002 Feb 07, 15:57
Location: UK

blog: file date anecdotes

Post by nikos »

here's the comment area for today's blog article found at
http://zabkat.com/blog/26Jun11-creation-date-memory.htm
User avatar
fgagnon
Site Admin
Site Admin
Posts: 3737
Joined: 2003 Sep 08, 19:56
Location: Springfield

Post by 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)?
User avatar
nikos
Site Admin
Site Admin
Posts: 16295
Joined: 2002 Feb 07, 15:57
Location: UK

Post by 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
Image
RightPaddock
Gold Member
Gold Member
Posts: 428
Joined: 2011 Jan 23, 18:58
Location: Sydney AU

Post by 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 :lol:

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

trash x2scrap.txt
Windows 10 Pro (64 bit) version 1809 - Xplorer2 version: Pro 2.5.0.4 [Unicode] x64 2014-06-21
User avatar
nikos
Site Admin
Site Admin
Posts: 16295
Joined: 2002 Feb 07, 15:57
Location: UK

Post by nikos »

not quite! but there is one way to reset the creation date which one day we will find out
User avatar
fgagnon
Site Admin
Site Admin
Posts: 3737
Joined: 2003 Sep 08, 19:56
Location: Springfield

Post by fgagnon »

nikos wrote: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). :o

So now I will try and remember to use it for adjusting creation, too ... at least from now until the rapture. ;)
Robert2
Gold Member
Gold Member
Posts: 700
Joined: 2004 Jun 17, 15:39

Post by Robert2 »

Actually, it is SHIFT+F12 :)
John_Gray
Member
Member
Posts: 12
Joined: 2010 Aug 01, 16:00

Post by 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
Member
Member
Posts: 16
Joined: 2004 Nov 16, 17:34

Post by 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.
User avatar
nikos
Site Admin
Site Admin
Posts: 16295
Joined: 2002 Feb 07, 15:57
Location: UK

Post by 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
Member
Member
Posts: 16
Joined: 2004 Nov 16, 17:34

Post by 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
Member
Member
Posts: 16
Joined: 2004 Nov 16, 17:34

Post by quietbritishjim »

quietbritishjim wrote: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]