Java Zip: extracting zips, 7zips and tars does not have consistent last modified time

Aspose.ZIP Product Family
1

Hello, I noticed this problem with many zips, but I will attach one for being sure that you can reproduce it.

With version 25.1, but also with the previous one (24.x), I noticed that if I extract a file by using Java Aspose Zip the last-modified time is not correct.

This is incostintent among archive types (zip, 7zip, tar, …) and zip files themselves.
I noticed that while on the version 24 the extracted result seemed to be “now” for all files and folders, in version 25.1 the last-modified date is only partially fixed, making it inconsistent.

Indeed, for zip and tar files I noticed that the files have the correct last-modified datetime while folders have “now”; for 7zip files only some files have the correct last-modified datetime.

For our purposes, it would be extremely important to keep for all files and folders the correct last-modified time, meaning the same behaviour of tools like 7zip, in which the resulted one is not “now” but the untouched last-modified time taken from the file before it was compressed.

Result for zip (the folder has wrong date):
image.png (28.6 KB)

Result for 7zip (also some file names are with wrong date):
image.png (27.2 KB)

Zip and 7zip file:
exWorldsCharactersCompressed.zip (1.8 KB)
exWorldsCharactersCompressed.7z (445 Bytes)

2

@mrossi

It seems you are experiencing inconsistencies with the last-modified timestamps when extracting files from various archive formats using Aspose.Zip. This issue appears to be present across different versions of the library, where the last-modified time for folders is often set to the current time instead of retaining the original timestamp.

From previous discussions, it has been noted that Aspose.Zip does maintain the creation and last-modified times for files, but there may be discrepancies with how these timestamps are handled for folders and certain file types, particularly with 7zip archives. This behavior can lead to situations where the extracted files do not reflect their original timestamps, which is crucial for your use case.

If you require the extracted files and folders to maintain their original last-modified timestamps, similar to how tools like 7zip operate, you might want to consider using alternative libraries or methods that ensure this functionality. For instance, the System.IO.Compression namespace in .NET has been mentioned as a viable option for preserving timestamps during file extraction.

If you continue to face issues, I recommend checking for updates or patches from Aspose that might address this behavior, or reaching out to their support for further assistance.

Sources:
[1]: Aspose.Zip (.NET) - Preserve time stamps on archived files

3

@mrossi
We have opened the following new ticket(s) in our internal issue tracking system and will deliver their fixes according to the terms mentioned in Free Support Policies.

Issue ID(s): ZIPNET-1264

You can obtain Paid Support Services if you need support on a priority basis, along with the direct access to our Paid Support management team.

4

@mrossi
We’ll review how we handle last modified datetime metadata and make it consistent for folders and file entries.

5

Could I ask with consistent what do you mean? The last modified datetime is an information that is also zipped, and the correct one, that most of the unzipping tools offer, is the one stored in the zip and not the extraction time.

In case you decide for a different way from the normal one, would you expose a way to configure the behaviour and choose it?

6

Not in a different way, we’ll set than datetime as it kept in headers. This enhancement will come in February version.

7

Ok, perfect!