The Case of the Failed File Compression

The other day, my colleague Bryce Cogswell tried to use Windows Explorer’s Send To Compressed (zipped) Folder feature to package up his latest Process Monitor source code updates to send me. Instead of presenting the compression progress, followed by an opportunity to edit the name of the resulting compressed file, Explorer aborted the compression with a File not found or no read permission error.

Bryce was perplexed. The error didn’t make sense because he obviously had read permission to the files in the selection, which he’d just finished editing, and compressing files shouldn’t involve a search that could result in a file not being found. He showed me the behavior by trying a few more times, all with the same outcome.

To investigate, we launched Process Monitor, reproduced the failure, stopped the capture, and scanned through the thousands of operations in the trace looking for errors. Several hundred events into the trace, we came across a sharing violation error that bore a closer look: When a process opens a file, it can specify if and how it wants to share the file with other processes while it has the file open. The three types of sharing are read, write, and delete, and each is represented with a flag that a process passes to the CreateFile API. In the operation that failed, Explorer didn’t pass any of the flags, indicating that it didn’t want to share the file.

For an open to succeed, the sharing mode of the opener must be compatible with the sharing allowed by a process that already has the file opened, so the explanation for the error was that another process already had the file opened. Looking at the trace, we discovered that the open operation immediately preceding the one with the error is an open of the same file by a process named Inort.exe. That confirmed that Explorer’s unwillingness to share the file conflicted with Inort having the file open, despite the fact that Inort specified read, write, and delete sharing in its open of the file.

Process Monitor had closed another case: Inort holding the file open when Explorer tried to open it was the cause of the sharing violation and almost certainly the reason for the misleading error message. Next we had to identify Inort so that we could come up with a fix or workaround. Process Monitor also answered that question: eTrust, Computer Associates’ antivirus scanner, was apparently opening the file to scan it for viruses but was interfering with the operation of Explorer. Antivirus should be invisible to the system, so the error revealed a bug in eTrust. The workaround was to set a directory filter that excludes the source directories from real-time scanning. Now I turned my attention back to the inefficiencies of Explorer’s compression feature. I captured a Process Monitor trace of the compression of a single file and counted the associated operations. Just for this simple case, Explorer opened the target .zip file 14 times, 12 of those before it had actually created the file and therefore with NOT FOUND results, and performed directory look ups of the target 19 times. It was also redundant with the source file, opening it 28 times and querying the file’s basic properties 17 times. It’s not like Explorer doesn’t give eTrust plenty of opportunities to cause sharing problems.

To verify that Explorer itself was at fault, and not some third-party extension, I looked at the stacks of various events. Zipfldr.dll, the Explorer file compression DLL, was in most of the stack traces, meaning that the compression engine was ultimately responsible for the waste. Further, the number of repetitious operations explodes when you compress multiple files.

Update: I’ve learned that Microsoft has updated the compression engine in Vista SP1 to perform fewer file operations.