Most of my individual and small group copying is done in an OFM. e.g. mc's <F5> (aka copy) apparently is configured by default on <F5> to preserve all attributes, including timestamp. It's what I expect every time I copy any normal file anywhere, regardless of copying tool used. To me, after decades of DOS and OS/2 use where such is the normal case, copying any regular file is equivalent to cloning it, making an exact duplicate. I find it inexplicable that gnu cp does not preserve all attributes by default, and little less difficult to comprehend how hard it can be in any exercise to make attribute preservation happen.
All, I haven't followed this thread, but I'm pretty knowledgeable about timestamps. Ie. Knowing how they work is core to my job function - computer forensics. Ntfs and Windows is my typical professional need, so I'm fuzzier with Linux. Feel free to ask questions. Felix, You may expect tools to preserve timestamps in general, but I can assure most modern copy tools don't. If you restrict yourself to the last modified datestamp, then you are closer to right. For Windows the "create" date is the date that a specific file was created on the current filesystem. Thus moving a file within a filesystem doesn't update the create date. Copying it to a thumb drive sets the create time to the current time. That is a feature of the Windows kernel. Tools like "cp --archive" have to override the default behavior by making calls to the kernel after the copy to reset the timestamps. All, NTFS is very cool in the way it handles timestamps. It maintains 2 sets of timestamps inside the filesystem metadata. One is primary and tools like "cp --archive" can adjust them via a Windows api after the fact to work as the tool designer wants them to. The other set is rarely used, but rigidly does what the Windows kernel wants. No api is provided to change them. Thus if a tarball (or zip file) is extracted in Windows with the restore timestamps option, the visible timestamps get reset to the original values, but the hidden set still have the time of the extraction. Having that hidden set can be helpful when working with malware that tries to hide by backdating itself. Fyi: I'm not familiar with any typical end-user tools that give access to the second set of timestamps. There are forensic tools that I use that do. A couple of those are in the opensuse distro. See analyzemft as an example. Greg -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org