ZIP unpack via TC and directories datestamps loss

[MaxX]

I've noticed that datestamps for directories become lost after unpacking ZIP with TC.
I really need to save original time for them.
It there any solution to unpack ZIPs with no loss of these dates?
Or how to recover these timestamps after unpack?

[gdpr deleted 6]

I can reproduce with some ZIP archives. Need to investigate further what particular ZIP archive data/flags triggers this behavior...

[gdpr deleted 6]

EDIT: Please check Petermad's post below. There is a copy setting in TC with regard to copying directory date+times, and chances are that you might have this setting unchecked...

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.

[hlloyge]

TCMD internal unzip creates folder with today's date, but files inside that folder are of correct date. Meanwhile, 7zips unzip creates folder and files inside with correct dates.
It doesn't matter which program created zip file, 7zip or tcmd internal... always the same.

[petermad]

TCMD internal unzip creates folder with today's date

Not here - I get the same date on unpacked directories as they have inside almost all zip archives.

But I have also enabled "Configuration" -> "Options..." -> "Copy/Delete" -> "General Copy+Delete options:" -> "Copy date/time of directories" - otherwise I don't get the stored timestamp on unzipped directories either.

[gdpr deleted 6]

But I have also enabled "Configuration" -> "Options..." -> "Copy/Delete" -> "General Copy+Delete options:" -> "Copy date/time of directories" - otherwise I don't get the stored timestamp on unzipped directories either.

I can confirm. Didn't expect a configuration setting for copy operations to influence unpacking operation, although it is somewhat logical. Well, good to know...

[ghisler(Author)]

It depends: Some ZIP packers store folders in the ZIP (including TC), and some just store file names with relative paths. In the first case, TC will unpack the folders with their timestamps if "Copy date/time of directories" is checked. In the second case, TC will just unpack the files because no folders are stored. The timestamps displayed for folders are the timestamps of the first file inside that folder.

[hlloyge]

Shouldn't that option be ignored when unpacking, so the unzip would unpack 'as is'?

[gdpr deleted 6]

It depends: Some ZIP packers store folders in the ZIP (including TC), and some just store file names with relative paths. In the first case, TC will unpack the folders with their timestamps if "Copy date/time of directories" is checked. In the second case, TC will just unpack the files because no folders are stored. The timestamps displayed for folders are the timestamps of the first file inside that folder.

Come to think of it, choosing the date+time of the first ZIP entry inside this folder is choosing an arbitrary date+time and thus rather meaningless. That entry could have the newest date+time, the oldest or some other of all date+times of the files in that folder.

Would it be possible to not show any date+time for such folder in TC?

If that is not possible for whatever reason, how about choosing the date+time of the newest file or sub directory instead. Since TC needs to enumerate all entries in a ZIP file anyhow to build the list for the file list window, there should be little additional overhead involved looking for the newest date+time. (That said, i would rather prefer to show no date+times for folders that have no date+time stored in the ZIP archive...)

[MVV]

Would it be possible to not show any date+time for such folder in TC?

I think it isn't easy. When some plugin doesn't report timestamps, TC shows the year 1600 or something like that (zero timestamp). So it would be more useful to show timestamp of newest file in that folder (however real timestamp may be older than timestamp of newest folder item because only add/remove/rename operations change folder timestamp).

[gdpr deleted 6]

Would it be possible to not show any date+time for such folder in TC?

I think it isn't easy. When some plugin doesn't report timestamps, TC shows the year 1600 or something like that (zero timestamp). So it would be more useful to show timestamp of newest file in that folder (however real timestamp may be older than timestamp of newest folder item because only add/remove/rename operations change folder timestamp).

That is true, indeed. Perhaps i am here just overthinking (or underthinking?)

[MaxX]

I have the great solution.
Let TC update timestamps for folders after the last file unpacked.