lastwritetime is changing while extracting a zipfile in c#?

Asked 15/12, 2010 at 8:57 Answered 16/12, 2010 at 4:2

I am using Sharpziplib version 0.86 to extract a zip file. It is working fine but while extracting a winzip file through code,Lastwritetime is changing in seconds...

Have used this also File.SetLastWriteTime(fullPath, theEntry.DateTime);

Actual file Lastwritetime:4/8/2010 2:29:03PM After zipping that file using winzip and while extracting that file using the code,extracted file Lastwritetime changes to 4/8/2010 2:29:04PM...Is there any fix for this???

Impetus answered 15/12, 2010 at 8:57 Comment(7)

I'm not sure if I understand your question. Do you mean while extracting the contents of a zip file with Sharpziplib the LastWriteTime of the zip file is changing and with WinZip only changes one time to one second latter? – Hyacinthhyacintha 15/12, 2010 at 9:1

@SoMoS:Not with winzip...am ectracting through code...there is a change in seconds...for this file 1 second...for other files 2 or 3 second difference is there – Impetus 15/12, 2010 at 9:3

Just looking from another angle; Are you sure it's the extraction that is creating the wrong timestamps on extracted files, or is the initial view you have (inside zipfile, before unzip) showing incorrect timestamps. Not sure how Zip stored it's datetime stamps, but i suspect it to be 'seconds since 1-1-70'. One of the two seems to be calculating it differently. – Pestilent 15/12, 2010 at 9:36

@Marvin Smit:ya i have checked with both winzip and through code....but while extracting through code this change in seconds occur – Impetus 15/12, 2010 at 9:42

Another thought: Just something which could 'cause this effect' is if the Zip library 'sets the lastwritetime' on creation of the file, then unzipping can take anywhere between <1 .. XX seconds. These seconds might be the difference you are seeying, which would make it 'a bug' in the library you are using. – Pestilent 15/12, 2010 at 9:42

@Marvin Smit:ya you are correct...i have posted this in Sharpziplib forum also.waiting for the response... – Impetus 15/12, 2010 at 9:45

@bala3569: My answer below would only explain a difference of one second I think. Not the 2 or 3 seconds you mention in your comment. – Lyndseylyndsie 15/12, 2010 at 18:28

I got this response from Sharpziplib Forum

This appears to be a WinZip bug. I have not noticed this before.

I did this test:

1) Use WinZip to add a file to a zip. In WinZip click Properties and Details. Look through the details list and find the file time stamp.

2) Use SharpZipLib to create a similar zip file with the same inputfile. Open the result in Winzip and look at the Properties > Details for the file time stamp.

My input file has a Modified timestamp (file properties) of 2010-12-14 15:51:28 and in my test, SharpZipLib stored it correctly in the zip, while WinZip stored it as 2010-12-14 15:51:30

In other words WinZip added 2 seconds when putting it into the zip. After extracting (either with WinZip or SharpZip), the Modified is now 15:51:30 instead of the original 15:51:28.

it is amazing that such an obvious bug in WinZip can have gone unreported and unfixed for so long. If you have a paid version you should certainly raise a bug fault with them.

I just remembered something about 2 second granularity in the old 8.3 file system timestamps.

Quick google found this ...

Quote "Original DOS file system had only 32 bytes to represent a file in the directory. The very restrictive 8.3 filename and the limited granularity (2 second) in file date are corrected in the Win32 file systems (VFAT)." from http://www.xxcopy.com/xxcopy15.htm

The Zip format only allows 2 second granularity in the standard time stamp entry.The date and time are encoded in standard MS-DOS format.

An optional NTFS Extra Data field (0x000a) can be included, which may hold last modification time, last access time and creation time. WinZip does not appear to create it. SharpZip will use it if present but as far as I can see, it is not created when using FastZip to create a zip. That might be a useful option to add to the code. You can certainly create it manually if using ZipFile.

Hope this helps, David

Impetus answered 16/12, 2010 at 4:2 Comment(1)

sounds like you have observed the combined effect of 2 different problems: The WinZip bug, and the 2-second precision associated to ZIP files. – Sungsungari 17/12, 2010 at 21:8

I think it might just be the operating system that is causing this. I've tried what happens in Explorer. I've got a text file with a modified time stamp of 17:06:45. I right click on the file and choose Send to | Compressed (zipped) folder. Then I right click on the new zip-file and choose Extract All... followed by Next, Next, Finish. Now the extracted text file has a time stamp of 17:06:46.

The same happens when I use 7-Zip, or WinRar. But then it only happens when using a .zip file. If I let them create a .7Z or a .RAR file the time stamp isn't changed.

Found an article on Wikipedia about the zip format. If you search it for "seconds" you'll find a section describing that the ZIP file system mimics the DOS FAT file system, which only has a time resolution of two seconds.

Lyndseylyndsie answered 15/12, 2010 at 13:22 Comment(2)

It's not the OS. The zip format by default stores times to a 2-second precision, so that can cause an off-by-one-second problem. Not off-by-two-or-three seconds, though. Zip tools can store higher resolution times, and there are standard ways to do this, but not all tools take advantage of the opportunity. – Sungsungari 17/12, 2010 at 21:6

@Cheeso: I know that, that's why I reference the Wikipedia article that describes the fact that the ZIP file system mimics the DOS FAT file system, which has this 2-second precision. – Lyndseylyndsie 17/12, 2010 at 21:17

Recommended topics

Hot tags