Greg Freemyer wrote on 2014-10-04 09:07 (UTC-0400):
...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.
One of the reasons why I stick to OFMs as much as practical.
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.
Proof I wasn't imagining differences according to context in the Win9x days, continuing with HPFS, and another reason for sticking with OFMs. :-p
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.
True for NTFS even when mounted and extracted using Linux?
Having that hidden set can be helpful when working with malware that tries to hide by backdating itself.
This good reason I hadn't considered. Outside of it and the work you do, are there others?
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. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation)
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org