Zip File Locked

Nov 3, 2008 at 6:33 PM
I am using the code below to create a zip file and add a file to it.  As soon as I leave the "using" block, I would expect the file to be created and completely unlocked.  But if I go double-click it in explorer I get an access denied -- in use by another process.  What could be the problem?  How could the file still be locked after the using block?  I need access to the file right away after it is created.

                    using (ZipFile zf = new ZipFile(fileName + ".zip"))
                    {
                        ZipEntry ze = zf[Path.GetFileName(fn)];
                        if (ze == null)
                            zf.AddFile(fn, "");
                        else
                            zf.UpdateFile(fn, "");
                        zf.Save();
                    }
At this point, the zip file is there, but it is locked.  It stays locked forever even after stopping and restarting IIS.  I can make a copy of it and open the copy and everything looks cool, but the original is locked forever.  Any ideas?  The file being zipped (fn in the above code) is not locked and I can open and delete that as I wish.

Thanks,
Jeff
Coordinator
Nov 3, 2008 at 6:44 PM
Edited Dec 18, 2008 at 3:07 PM
do you have anti-virus software? Sometimes the AV software can be configured to open and scan zip files.
If you do, I suggest trying a test with the AV software disabled.
If that is not the case, there are tools that can help track down which process has the zip file open (locked).
The sysinternals tool ProcMon is a good one, and is a free download from Microsoft.
Nov 3, 2008 at 8:32 PM
Thanks for the reply. 
I have no AV software on this machine.  (Though it is Vista with UAC enabled, but I don't think that is the problem).

I will try the procmon utility and report the results back here.  My guess is that it will just say that IIS has it locked, but we'll see...
Jeff
Nov 3, 2008 at 9:50 PM
Edited Nov 3, 2008 at 10:33 PM
[Edit: I had posted a long dump of ProcMon output, but later found the problem.  I removed the procmon output and replaced it with this message of the actual solution]

I think I found the problem: The Zip library is creating a temp file in my c:\windows\temp folder and then copying that file over to its final destination.  The permissions in c:\windows\temp are vastly different from the folder where I have the zip files.  For instance, it is set so that changes to files in c:\windows\temp requires a UAC validation.  When that file is copied over to c:\src\se\data\files something gets broken.  When I try to open the file I just get access denied instead of a UAC request.  When  I disabled UAC and rebooted, I could now open the zip file that was created, but my program still could not. 

This was also because of permissions -- my anonymous web account does not have access to open zip files in c:\windows\temp.  When the file was copied over, it maintained those original permissions instead of picking up permissions of the destination folder.  So even though my anon account had full access to c:\src\se\data\files it could not open that file because its permissions were established by c:\windows\temp.

I thought this Zip library did not create a temp file?  I seem to remember reading that in its features somewhere.  Well anyway, I think this was the problem -- mismatched permissions between the temp folder and the destination folder.

Jeff

Coordinator
Nov 3, 2008 at 10:47 PM
Edited Dec 18, 2008 at 3:08 PM
Ahh, I see.

The zip library creates a temp file when saving to a file.  if saving to a stream, there is no temp file created.

you can set the location of the temp file using the TempFileFolder property on the ZipFile class.  It is especially recommended to do this in ASP.NET applications, or any app hosted in IIS. (Eg, WCF app, etc)