Author: elgonzo
Posted: Thu May 05, 2016 5:33 pm (GMT -6)
TL;DR: Your ZIP file(s) in all likelihood do not store date+time for directories. If directory date+times are important for you, make sure they are added when creating the ZIP archive(s). Btw, TC's ZIP packer does store directory date+times.
After unpacking a ZIP archive, if you want to correct the date+time for directories which do not have their date+time stored in the ZIP archive, use some script or program to set the directory date+time according to your needs. If you want the date+time of the directory to be the same as the newest file in that directory, you might want to give FolderTimeUpdate (GUI+command line, http://www.nirsoft.net/utils/folder_time_update.html) a try...
-----------------
Okay, some technical explanations about what is happening here. The observed behavior (whether TC sets the date+time of a directory or not) depends on whether directories have their own local file header in the ZIP archive.
A "local file header" (LFH) is a data structure in a ZIP file, which stores date+time of an entry among other things. If a directory has its own LFH in a ZIP archive, then TC uses the date+time stored in this LFH for setting the date+time of the directory.
However, LFHs for directories are not mandatory. If there is no LFH for a directory in a ZIP file (which is allowed by the ZIP format spec.), then there is also no date+time for that directory stored.
Side note: Now, if you look into a ZIP archive with TC, you will notice that TC shows date+time also for directories which don't have their own LFH in the ZIP archive. So, what date+time is TC showing in these cases? TC simply shows the date+time from the first entry in the ZIP archive whose file path contains the directory in question.
_________________
Windows 7 Pro x64 SP1, Aero enabled, Dual-display extended desktop
Posted: Thu May 05, 2016 5:33 pm (GMT -6)
TL;DR: Your ZIP file(s) in all likelihood do not store date+time for directories. If directory date+times are important for you, make sure they are added when creating the ZIP archive(s). Btw, TC's ZIP packer does store directory date+times.
After unpacking a ZIP archive, if you want to correct the date+time for directories which do not have their date+time stored in the ZIP archive, use some script or program to set the directory date+time according to your needs. If you want the date+time of the directory to be the same as the newest file in that directory, you might want to give FolderTimeUpdate (GUI+command line, http://www.nirsoft.net/utils/folder_time_update.html) a try...
-----------------
Okay, some technical explanations about what is happening here. The observed behavior (whether TC sets the date+time of a directory or not) depends on whether directories have their own local file header in the ZIP archive.
A "local file header" (LFH) is a data structure in a ZIP file, which stores date+time of an entry among other things. If a directory has its own LFH in a ZIP archive, then TC uses the date+time stored in this LFH for setting the date+time of the directory.
However, LFHs for directories are not mandatory. If there is no LFH for a directory in a ZIP file (which is allowed by the ZIP format spec.), then there is also no date+time for that directory stored.
Side note: Now, if you look into a ZIP archive with TC, you will notice that TC shows date+time also for directories which don't have their own LFH in the ZIP archive. So, what date+time is TC showing in these cases? TC simply shows the date+time from the first entry in the ZIP archive whose file path contains the directory in question.
_________________
Windows 7 Pro x64 SP1, Aero enabled, Dual-display extended desktop