Fail to restore dir. timestamp in some systems/files
A free file archiver for extremely high compression
Brought to you by:
ipavlov
Menu
▾
▴
#1440 Fail to restore dir. timestamp in some systems/files
Tested system 1
OS: Windows 98SE
Memory: 384MB
CPU: Intel Pentium II 400
Sound: ESS Solo-1
Video: Neomagic MagicMedia 256AV
Tested system 2
OS: Windows XP SP2
Memory: 4096(3264)MB
CPU: Intel Pentium D 805
Sound: Realtek ALC888
Video: ATI Radeon HD 4850
When extracting a directory object within an archive in tested system 1, 7-Zip does not restore the timestamp for the directory. The bug usually does not occur in tested system 2, but it can depending on archive contents (eg: MAMEUI32 0.149 32-bit Windows build[1]).
In the case of tested system 2 bug, it occured when extracting to a NTFS drive, but not on a FAT32 drive. A known workaround for NTFS drive extraction is to extract the archive twice to the same location, but choose not to replace any extracted files in second session. In seems that 7-Zip enters some sort of race condition where the extracted directory objects lost their timestamps because objects stored inside the directories are extracted after the directories have been extracted, but this condition does not happen consistently. It also exposes another bug where 7-Zip fails to ask user to replace directory objects as it does to files. 7-Zip should extract directory objects after the extractions of corresponding file objects, with the innermost directories be extracted first, so that timestamps in archives are not lost during extraction. 7-Zip should also ask users over replacing existing directory objects during extraction. However, given a directory object usually does not have contents beyond metadata, the replacement dialog should be redesigned so that 'Yes to All', 'No to All', 'Auto Rename' behaviours applies only to one of files or directories types independently, and user can choose to replace only metadata or content for any given object.
As for tested system 1 bug, the bug happens in many other programmes too, except in DosZip commander, where it can change a directory's last modification date without problem, but not creation and last access dates. It seems 7-Zip tries to alter a directory's creation date instead of last modification date. If DosZip commander can alter directory timestamps, there should be no reason why it cannot be done in 7-Zip.
[1] http://www.progettosnaps.net/UI_Museum/MAMEUI32_0.149_11-06-2013.7z
Try 7-Zip 9.30 alpha.