Menu
When creating a tar archive with -c, the modification time seems to be changing, specifically it cuts off the time after the decimal, leaving the modtime to be just the integer value of what it was.
Notice: ```
[localhost] $ mkdir test
[localhost] $ stat test
File: ‘test’
Size: 4096 Blocks: 8 IO Block: 4096 directory
Modify: 2016-07-18 17:01:33.116807520 -0400 # <------ Notice exact time
[localhost] $ tar -cf test.tar test
[localhost] $ tar -xf test.tar
[localhost] $ stat test
File: ‘test’
Size: 4096 Blocks: 8 IO Block: 4096 directory
Modify: 2016-07-18 17:01:33.000000000 -0400 # <------ Notice how time is rounded
(I removed irrelevant parts from output of stat for readability)
I've inquired man tar, but couldn't find an option that'll preserve exact modification time in nanoseconds. Could someone explain why such behavior is occurring? Or is this expected during tar creation.
Update: So far no luck, I tried playing around with tar options but most of options that deal with time are related to a files' access time, and not modtime. The ones that do deal with modtime change the modtime, which isn't something I'm looking for.
334
Tar is a common command line tool for archiving files and directories. It's famous for the capacity of preserving file permission and ownership. Unlike other archiving tools, say zip or gzip, tar itself doesn't compress files during archive creation.
By default, tar will preserve file permissions and ownership when creating the archive. To extract file permissions and ownership, you will need to run tar as root when extracting, since changing file ownership usually requires superuser privileges.
Overwrite existing files and directory metadata when extracting files from an archive. This causes tar to write extracted files into the file system without regard to the files already on the system; i.e., files with the same names as archive members are overwritten when the archive is extracted.
tar does preserve the hardlinks. This flag represents a file linked to another file, of any type, previously archived. Such files are identified in Unix by each file having the same device and inode number.
Just in case anyone googling the same issue stumbles upon this thread (like I did):
The solution (at least one of them) is to use the -H option, as answered here:
https://unix.stackexchange.com/questions/397130/tar-how-to-preserve-timestamps-down-to-more-than-a-second-of-precision/397132#397132
The tar(1) manpage does not point out the practical implications of the -H arguments at all; I think it would be very helpful if a search for a likely keyword ("nanosecond", "second", "resolution", etc.) led to the paragraph on -H.
192
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
