I noticed a change in zip archives creation, not mentioned in History.txt:
Previously the "tc" parameter was switching between the NTFS timestamps (modification, creation, access, 100ns precision) and the DOS timestamp (modification only, 2s precision) and by default all NTFS timestamps were stored.
In v22 quite a few things changed:
- "tc" only controls the creation time
- additional parameters "tm" and "ta" have been added to control modification and access times correspondingly
- "tc" and "ta" are off by default.
Surprisingly, "off by default" doesn't mean "not stored".
A zip archive always has allocated space for all three NTFS timestamps, same as before, but now only modification time is populated by default, the other two are filled with zeros.
Is it actually by design and expected? Keeping empty timestamps looks like a waste of space (24 bytes or so for each file in an archive). If it's not possible to allocate them individually, why not fill all by default, same as before? Not to mention that not filling them by default breaks backward compatibility to some extent.
Thanks
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
There are at least 2 drawbacks with these timestamps:
- Last access and creation timestamps can carry some private information about time of user actions. And maybe someone doesn't want it.
- Also if you compress same files to zip archive several times, you will have different results with changed access timestamps.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Last access and creation timestamps can carry some private information about time of user actions
Indeed, but so does the modification timestamp, probably even more often, and people actually concerned with digital footprints would supposedly thoroughly inspect the final result before handing it to anyone anyway.
if you compress same files to zip archive several times, you will have different results with changed access timestamps
Isn't that already covered by -ssp?
Anyway, I'm not suggesting to change anything, just wanted to make sure it's intentional.
Thank you for the explanation.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, it's intentional.
All zip archives already carry Modified timestamp. So it's expected feature for users.
But creation and last access timestamp can be unexpected feature, if user sends zip archive to someone else.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
I noticed a change in zip archives creation, not mentioned in History.txt:
Previously the "tc" parameter was switching between the NTFS timestamps (modification, creation, access, 100ns precision) and the DOS timestamp (modification only, 2s precision) and by default all NTFS timestamps were stored.
In v22 quite a few things changed:
- "tc" only controls the creation time
- additional parameters "tm" and "ta" have been added to control modification and access times correspondingly
- "tc" and "ta" are off by default.
Surprisingly, "off by default" doesn't mean "not stored".
A zip archive always has allocated space for all three NTFS timestamps, same as before, but now only modification time is populated by default, the other two are filled with zeros.
Is it actually by design and expected? Keeping empty timestamps looks like a waste of space (24 bytes or so for each file in an archive). If it's not possible to allocate them individually, why not fill all by default, same as before? Not to mention that not filling them by default breaks backward compatibility to some extent.
Thanks
There are at least 2 drawbacks with these timestamps:
- Last access and creation timestamps can carry some private information about time of user actions. And maybe someone doesn't want it.
- Also if you compress same files to zip archive several times, you will have different results with changed access timestamps.
Indeed, but so does the modification timestamp, probably even more often, and people actually concerned with digital footprints would supposedly thoroughly inspect the final result before handing it to anyone anyway.
Isn't that already covered by -ssp?
Anyway, I'm not suggesting to change anything, just wanted to make sure it's intentional.
Thank you for the explanation.
Yes, it's intentional.
All zip archives already carry Modified timestamp. So it's expected feature for users.
But creation and last access timestamp can be unexpected feature, if user sends zip archive to someone else.