This project is read-only.

Can't delete the zip when using Zip64

Nov 23, 2010 at 12:13 AM


I'm using  ver with 2008

If I create a zip using    zip1.UseZip64WhenSaving =Zip64Option.none  then I everything is god and I can delete the resultant zip file.

However if make a zip using    zip1.UseZip64WhenSaving =Zip64Option.always   then I can not  delete the resultant zip.  Windows states the zip file is in use by another process, even after a reboot.


My code is -

            Using zip1 As ZipFile = New ZipFile
                zip1.CompressionLevel = My.Settings.ZipLevel                         ' Ionic.Zlib.CompressionLevel.Level6
                zip1.UseZip64WhenSaving = My.Settings.Zip64Mode            ' Ionic.Zip.Zip64Option.Always
                Me._entriesToZip = zip1.EntryFileNames.Count
                AddHandler zip1.SaveProgress, New EventHandler(Of SaveProgressEventArgs)(AddressOf Me.zip1_SaveProgress)
                zip1.Save(bufferFolder & ZipName)
            End Using


Am I doing something wrong or have I found a bug?

How do you get rid of the faulty zip?  can't rename it but can copy it. The copy can not be deleted either. Can not add or delete any contents of the zip but can restore it.

Now have a hard drive full of test zips that I can't kill off...




Nov 23, 2010 at 1:51 AM

I don't know; maybe you have an anti-virus program that is holding the file open.  It's very unusual that you cannot delete the files even after a reboot, unless some process immediately opens it.  Which makes me think of an anti-virus program.  It's possible that the AV program doesn't know how to properly read zip64 files, which causes the file to stay open.  I'm just guessing here.

If you get the sysinternals tools, there's a handle tool that lists the files that are open by all processes in the operating system. This may tell you what is holding the file open, preventing it from being deleted.


Nov 23, 2010 at 2:24 AM

Thanks Cheeso,

I had a look at the Handles tool with interesting results. It reports that only 'explorer' has handles to any of  these dud zip files.

The only explorer instance is that of the Windows (XP) gui. If I kill that process then I can delete the dud zip via the command line.


This only occurs with zip64 enabled and is regardless of file sizes or quantity.

If I copy the dud zip file to another pc, I can't delete it from there either.

There is something very different about these files in that Explorer is holding onto them...  Any clues


I noticed you also have a ionic.tar compressor. If I can't use zip64 then I might look at TAR.  Can you tell me what the limits are for TAR files? I need way more than 4.2Gb, more like 20Gb.

Is all this Ionic stuff your work? Bloody good effort.




Nov 23, 2010 at 2:57 AM

Hmm, yep, could be that explorer for some reason wants to read that file, can't, and then keeps trying.  ?? odd.  I can't imagine why that would be.

I have a test suite developed for DotNetZip and I run it with every binary release.  It creates hundreds of zip64 files, and deletes them when it's finished.  This most recently ran on a computer running Vista SP1.  Never had a problem with Explorer.  I don't believe I ever ran the test suite on Windows XP.

Do you by chance have another zip tool installed on your computer?  Something that adds an Explorer extension, that might try to read every zip file it finds? Just an idea.  Maybe it's an explorer extension.

About the tar thing - yes that is also my work.  Tar+GZip It's probably better for you if you have many many files.  The compression gets better when you compress large streams.  If the files you are compressing are already large, then there's not going to be a large difference in compression between ZIP and tar+gzip. The other distinguishing factor is usually that zip files can be read by various tools, and tar/gz files require "less popular" tools, which means they're harder to share.  But in your case you're talking about zip64, which honestly, isn't widely supported, so a file formatted that way will not be shareable anyway.  Tar+GZ will be more easy to share than zip64, I think.

anyway good luck figuring this all out.




Nov 23, 2010 at 3:07 AM

Thanks Mate


I think TAR is the go then.

This a Windows app that feels out into an OSX network, archives a heap of large graphics files and moves them off to data tapes. If ever they are restored, it will be on a Mac so Tar is a more obvious solution. Files are typically 1-2Gb.

FYI Stuffit for Mac reads zip64 nicely


You could be onto something with the zip tools. I think all machines have Zipgenius installed as well so thats worth investigating although I'd expect that to lock standard zips as well as 64's.

I'll let you know what transpires but I think Tar is the eventual solution.


many thanks, love your work.



Nov 23, 2010 at 9:31 PM

In case someone else has a similar problem, ZipGenius ( is the problem.

Uninstalling this removed all problems. For some reason it opens handles to (only) zip64 files at boot up preventing their deletion. Non zip64 files are ok.


Thanks for your help Cheeso

Nov 24, 2010 at 5:30 PM

Glad you worked it out Malcomm, and thanks for the compliments.

good luck.