Maintaining File Timestamps (again)

Dec 10, 2009 at 4:44 PM

I am using DotNetZip (ver 1.8) for the first time and continue to have problems maintaining the time stamps for files included in the archive files I create. I have reviewed the documentation and other discussions but can not seem to find a solution to my problem. Whenever I add files to an archive and then extract them (using Windows internal capability) all the time stamps are set to the original modification date/time. As per the documentation and discussions, the code I am using to add files to the archive is:

using(ZipFile archive = new ZipFile())

{

...

archive.AddFile(filepath);

archive.Save(archivefilepath)

...

}

I have tried implementing this in a variety of ways and always get the same results. If it matters, I am using Microsoft Visual C# Express Edition on Windows Vista Home Premium (64-bit).

Thanks in advance for any help.

 

Coordinator
Dec 10, 2009 at 5:49 PM

You described what you are seeing, but you didn't describe what you expect to be seeing.

And, the behavior you described -  where the extracted files get their modification time from the originally zipped files -  is the documented, expected behavior.

 

 

Dec 10, 2009 at 7:50 PM

I apologize for not being clearer. The modified date information is correct when the files are extracted from the archive, however the Created and Last Accessed dates do not reflect those of the original file. Instead they are the same as the Last Modified date. Is this the expected behavior?

Thanks

Coordinator
Dec 11, 2009 at 3:07 AM

Ah, ok, now I understand.

I don't know how Windows works, when it extracts files from a zip.  What happens if you extract the zip file, using DotNetZip?  Do the file timestamps get set the way you expect?  What happens if you extract another zip file, one not created by DotNetZip? (Maybe it's created by Windows as a compressed folder.)  Do you get files with the expected values for the 3 timestamps?

When creating  zip file with DotNetZip , by default  each entry will get its created, lastmodified and last accessed timestamps set, internally in the zip entry metadata.  You may have seen the documentation that describes this timestamp information as being stored in an "extra" field inside the zip file.  The "extra" field is part of the zip specification, but it was added after the original zip format was created.  As a result, not every zip tool or library reads or writes the extended timestamps.  DotNetZip does. 

Once you have a zip file with the extended timestamps, it is then up to the extracting application or tool - in your case Windows Explorer I guess - to apply those timestamps to the files it extracts.  I don't know if Windows does this.  It wouldn't surprise me to learn that Windows doesn't take advantage of the extended timestamps, but I don't know.

That's why I asked what happens if you extract with a DotNetZip application.  In that case, if the timestamps on the extracted files match what you expect, it indicates the timestamps are correctly set in the zipfile, and they are being used upon extraction.  I'd be very surprised to hear this is not the case. I have a number of tests covering this in the test suite that I run before posting a release.  I don't have a test case to check the resulting file timestamps for the situation where Windows is used to extract.   You should be able test that pretty easily.  


Windows supports zip files, but not all aspects of the ZIP specification.  One thing it doesn't support is UTF-8 encoding for entry names.  It also does not support WinZip encryption.  It's possible that Windows also doesn't support the extended timestamps.