在c#中提取zipfile时lastwritetime正在更改？

我正在使用Sharpziplib 0.86版来提取zip文件。它工作正常，但在通过代码提取winzip文件时，Lastwritetime在几秒钟内发生变化

还使用了

File.SetLastWriteTime（完整路径，entry.DateTime）

实际文件最后写入时间：
4/8/2010 2:29:03PM
使用winzip压缩该文件并使用代码提取该文件后，提取的文件Lastwritetime将更改为
4/8/2010 2:29:04PM
…是否有任何修复方法？？？
我认为可能是操作系统导致了此问题。我试过在Explorer中发生的事情。我有一个修改过的时间戳为17:06:45的文本文件。我右键单击该文件并选择发送到|压缩（压缩）文件夹。然后我右键点击新的zip文件并选择全部解压缩。。。接着是下一个，下一个，完成。现在，提取的文本文件具有17:06:46的时间戳

当我使用7-Zip或WinRar时也会发生同样的情况。但只有在使用.zip文件时才会发生这种情况。如果我让他们创建一个.7Z或.RAR文件，时间戳不会改变

找到关于zip格式的信息。如果你搜索“秒”，你会发现一个部分描述ZIP文件系统模仿DOS FAT文件系统，它的时间分辨率只有两秒。
我从Sharpziplib论坛得到了这个回复

嗨

这似乎是一个WinZip错误。我以前没有注意到这一点

我做了这个测试：

1） 使用WinZip将文件添加到zip。在WinZip中，单击属性和详细信息。查看详细信息列表并找到文件时间戳

2） 使用SharpZipLib创建具有相同inputfile的类似zip文件。在Winzip中打开结果，查看文件时间戳的属性>详细信息

我的输入文件的修改时间戳（文件属性）为2010-12-14 15:51:28，在我的测试中，SharpZipLib将其正确存储在zip中，而WinZip将其存储为2010-12-14 15:51:30

换句话说，WinZip在将其放入zip时增加了2秒。
提取（使用WinZip或SharpZip）后，修改后的值现在是15:51:30，而不是原来的15:51:28

令人惊讶的是，WinZip中如此明显的一个bug竟然这么长时间没有被报告和修复。如果你有一个付费版本，你肯定会对它们提出错误

我只记得旧的8.3文件系统时间戳中大约2秒的粒度

快速谷歌找到这个

Quote“原始DOS文件系统只有32个字节来表示目录中的文件。在Win32文件系统（VFAT）中，非常严格的8.3文件名和有限的文件日期粒度（2秒）得到了纠正。”
从

Zip格式在标准时间戳条目中仅允许2秒的粒度。日期和时间以标准MS-DOS格式编码

可以包括可选的NTFS额外数据字段（0x000a），该字段可以保存上次修改时间、上次访问时间和创建时间。WinZip似乎没有创建它。SharpZip将使用它（如果存在的话），但据我所知，它不是在使用FastZip创建zip时创建的。这可能是添加到代码中的一个有用选项。如果使用ZipFile，您当然可以手动创建它

希望这有帮助，
大卫
我不确定我是否理解你的问题。你的意思是，当使用Sharpziplib提取zip文件的内容时，zip文件的最后写入时间正在更改，而使用WinZip只会更改一次到一秒吗？@SoMoS:不使用WinZip…我正在通过代码提取…有一个以秒为单位的更改…对于此文件，1秒…对于其他文件，2秒或3秒的更改只是看起来不同而已从另一个角度看,；您确定是提取在提取的文件上创建了错误的时间戳，还是您的初始视图（在zipfile内部，解压之前）显示了错误的时间戳。不确定Zip是如何储存它的日期戳的，但我怀疑它是“从1-1-70开始的秒数”。这两种方法中的一种计算方式似乎不同。@Marvin Smit:Ye我已经用winzip和直通代码进行了检查……但是在通过代码提取时，这种变化会在几秒钟内发生另一种想法：可能导致这种效果的原因是，如果Zip库在创建文件时“设置了lastwritetime”，然后解压可以在操作系统之外的任何地方进行。默认情况下，zip格式以2秒的精度存储时间，因此可能会导致关闭1秒的问题。不过，在两三秒钟内还没有结束。Zip工具可以存储更高的分辨率时间，有标准的方法可以做到这一点，但并不是所有的工具都能利用这个机会。@Cheeso:我知道，这就是为什么我引用Wikipedia的文章来描述Zip文件系统模仿DOS FAT文件系统这一事实，听起来你已经观察到了两个不同问题的综合影响：WinZip错误和与ZIP文件相关的2秒精度。