I’ve run into a problem on Windows that appears to be specific to users of TrendMicro’s Officescan anti-virus product. At least, I’ve only had the issue reported to me by users of the Trendmicro product. The same problem occurs with unzip 6.0 and earlier versions.
The symptom is unzip will intermittently fail with the message “CreateFile() error 32 when trying set file time”.
I have not been able to reproduce this error myself, but I believe unzip is hitting the problem where the anti-virus program is keeping a file lock while the AV program scans the new file content. Microsoft describes the problem generically in this MSDN article: http://support.microsoft.com/kb/316609
I implemented the retry suggested in the MSDN article and confirmed with one user consistently hitting the issue that they no longer see it.
Just throwing this out as a suggestion for a future release to make the unzipper more robust on Windows.
Thanks for the report and the suggestion.
Ok. I'll look around and see if I can add some similar code.
Was the only reported complaint that "when trying set file time" one?
There's some similar code for directories (with a different message),
but I suppose that no one runs an anti-virus scan on an actual directory
file, so that section should be safe(r).
In the current development code, there are two of these (one for wide
Unicode names, one for narrow/old), but, on the bright side, the
messages now say "when trying to set file time". So, just when the
message begins to look better, perhaps no one will ever see it again.
The only report I had was for the "set file time" occurrence in close_outfile(). I also didn't think the problem would apply to directories and I didn't make the changes for that function.
I did make similar changes in stamp_file(), but I didn't take the time to really understand if that was necessary. I also didn't take the time to understand where nt.c is used.
Sounds right to me.
stamp_file() appears to me to be limited to setting the date-time on
the archive itself (for "unzip -T"), which should be a less likely
trouble spot, but I'll add the retry code there, too.
That seems to be used to set the NT Security Descriptor stuff
("unzip -X"), so I'd guess that it's about as vulnerable as the
date-time code (if the victim specifies "-X").
Your search for CreateFile seems to agree with mine, so, with any
luck, the retry code for non-directory files should be in the next beta
kit.
Thanks again.