Sorry if I'm repeating old debates, but I've searched and found hardly anything. I think that 7-Zip needs to get much more serious about storing and restoring file times. I would like to know to what precision file times are stored (and this should be in the documentation). As you will know, precision varies wildly across file systems. FAT stores only to a precision of two seconds, but on NTFS file times are 64-bit numbers counting 100-nanosecond intervals since 1601 (quote from Wikipedia), and on ZFS seems to have nanosecond precision. I would really like to know how 7-Zip deals with this admittedly complicated situation. Then the other issue is creation time - it's often been asked, but responses from Igor have been very short indeed. There seems to be a place in the source that would restore creation times, but all I've seen in the forum are responses like "it's a disabled option" or "7-Zip does not restore creation times". Compare with this extract from WinRAR's version history at "http://www.buyrar.com/WinRARVersions.asp":
====
v3.20
1. Previous WinRAR and RAR versions stored only the file modification time and only in DOS FAT format with 2 seconds precision. While it was enough for FAT, modern file systems provide a higher precision. Now RAR format can preserve modification, creation and last access time with the precision up to 0.0000001 second.
The following changes had been done to support this facility:
a) new "Time" part of archiving dialog includes "File time to store" options controlling file time processing. Other time related options also had been moved from "Backup" to "Time" section;
b) new "Advanced" part of extraction dialog contains "File time" options allowing to select time fields to restore;
c) command line -ts switch chooses time fields to process and precision of these fields;
Time precision provided by ZIP format is not changed and equal to 2 seconds.
===
RAR is at a definite advantage here (0.0000001s = 100ns = NTFS precision), and I'd love to see 7-Zip catch up and possibly overtake. A good time handling strategy is vital for backup tools and other programs that check times - modification time as well as creation and access(!) time. Then there is the bug that directory times need to be restored as well, and that means restoring them after the last file within that directory has been restored. (Well, I haven't checked but seen a report on the forum, and I assume the bug was correct and still exists.)
RAR seems to have the edge with other types of "metadata" too, being able to store NTFS streams and security data as well as OS/2 extended attributes (Wikipedia). It's of course impossible to determine what to include and what not to, as technology keeps changing. But it would be good to provide for a kind of extensible metadata storage system, where a best effort could be made to store what's available (provide as much time precision as the local filesystem offers, for example, even for future file systems with, who knows, perhaps picosecond precision - or consider the various access permission schemes) and restore as much as possible on extraction. GUI support to choose what to store would of course be difficult, although not impossible, if some kind of attribute naming scheme could be developed.
But for now I'm most of all seeking comment on file times - what's the precision, when can we see creation and access times being restored, and directory times given the right treatment?
Thanks
Sebastian Lisken
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
7-Zip uses NTFS time (UTC time in 100-nanosecond intervals). 7-Zip stores only last_modification_time in .7z archives now.
Also 7-zip puts folder items to the end of .7z archives. So it will be able to restore modification_time for folders at extracting.
Note also that daylight time changings can change offset from UTC.
So if you use "Update" operation, it's better to use same time system in archive and in filesystem:
1) NTFS + .7z (UTC time).
2) FAT + .zip (Local time).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for the response, good to know. Like I said, this should by in the documentation somewhere. I'm willing to write this into a paragraph or two and send it. Thanks also for the time zone offset remark. I see from a quick test that using ZIP on NTFS does not cause a problem for a file that's put into a new archive and immediately extracted again. Presumably the problem would occur if one changes the time zone offset in between or if DST starts or end between archiving and extracting. I wonder if the problem could be improved or otherwise documented as well.
I can see that increasing the precision would not be a priority and would require using more than 64 bits. My ZFS example was hypothetical, although I'm sure it will be in issue for someone some time. :-) But I would like to know if we can hope for creation and access times being stored in a not too distant new version of 7-Zip.
Sebastian Lisken
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sorry if I'm repeating old debates, but I've searched and found hardly anything. I think that 7-Zip needs to get much more serious about storing and restoring file times. I would like to know to what precision file times are stored (and this should be in the documentation). As you will know, precision varies wildly across file systems. FAT stores only to a precision of two seconds, but on NTFS file times are 64-bit numbers counting 100-nanosecond intervals since 1601 (quote from Wikipedia), and on ZFS seems to have nanosecond precision. I would really like to know how 7-Zip deals with this admittedly complicated situation. Then the other issue is creation time - it's often been asked, but responses from Igor have been very short indeed. There seems to be a place in the source that would restore creation times, but all I've seen in the forum are responses like "it's a disabled option" or "7-Zip does not restore creation times". Compare with this extract from WinRAR's version history at "http://www.buyrar.com/WinRARVersions.asp":
====
v3.20
1. Previous WinRAR and RAR versions stored only the file modification time and only in DOS FAT format with 2 seconds precision. While it was enough for FAT, modern file systems provide a higher precision. Now RAR format can preserve modification, creation and last access time with the precision up to 0.0000001 second.
The following changes had been done to support this facility:
a) new "Time" part of archiving dialog includes "File time to store" options controlling file time processing. Other time related options also had been moved from "Backup" to "Time" section;
b) new "Advanced" part of extraction dialog contains "File time" options allowing to select time fields to restore;
c) command line -ts switch chooses time fields to process and precision of these fields;
Time precision provided by ZIP format is not changed and equal to 2 seconds.
===
RAR is at a definite advantage here (0.0000001s = 100ns = NTFS precision), and I'd love to see 7-Zip catch up and possibly overtake. A good time handling strategy is vital for backup tools and other programs that check times - modification time as well as creation and access(!) time. Then there is the bug that directory times need to be restored as well, and that means restoring them after the last file within that directory has been restored. (Well, I haven't checked but seen a report on the forum, and I assume the bug was correct and still exists.)
RAR seems to have the edge with other types of "metadata" too, being able to store NTFS streams and security data as well as OS/2 extended attributes (Wikipedia). It's of course impossible to determine what to include and what not to, as technology keeps changing. But it would be good to provide for a kind of extensible metadata storage system, where a best effort could be made to store what's available (provide as much time precision as the local filesystem offers, for example, even for future file systems with, who knows, perhaps picosecond precision - or consider the various access permission schemes) and restore as much as possible on extraction. GUI support to choose what to store would of course be difficult, although not impossible, if some kind of attribute naming scheme could be developed.
But for now I'm most of all seeking comment on file times - what's the precision, when can we see creation and access times being restored, and directory times given the right treatment?
Thanks
Sebastian Lisken
7-Zip uses NTFS time (UTC time in 100-nanosecond intervals). 7-Zip stores only last_modification_time in .7z archives now.
Also 7-zip puts folder items to the end of .7z archives. So it will be able to restore modification_time for folders at extracting.
Note also that daylight time changings can change offset from UTC.
So if you use "Update" operation, it's better to use same time system in archive and in filesystem:
1) NTFS + .7z (UTC time).
2) FAT + .zip (Local time).
Thanks for the response, good to know. Like I said, this should by in the documentation somewhere. I'm willing to write this into a paragraph or two and send it. Thanks also for the time zone offset remark. I see from a quick test that using ZIP on NTFS does not cause a problem for a file that's put into a new archive and immediately extracted again. Presumably the problem would occur if one changes the time zone offset in between or if DST starts or end between archiving and extracting. I wonder if the problem could be improved or otherwise documented as well.
I can see that increasing the precision would not be a priority and would require using more than 64 bits. My ZFS example was hypothetical, although I'm sure it will be in issue for someone some time. :-) But I would like to know if we can hope for creation and access times being stored in a not too distant new version of 7-Zip.
Sebastian Lisken