Unable to move the replacement file to the file to be replaced. (When adding files to existing archive).

Jun 11, 2008 at 4:05 PM
First - thanks to Chesso for the great work and effort thus far.

I need to add a large amount of files to a zip file (the file sizes are very small), but I need to verify which files get added successfully. I am unable to add files successfully to an existing .zip archive (using version 1.5.0.7). Simple example:

        Using oZip As New ZipFile("D:\Data_Archive.zip") 'Create initial archive
            oZip.AddItem("D:\Data.bin", "")
            oZip.Save()
        End Using

        Using oZip2 As New ZipFile  'Start adding new files to zip file.
            oZip2.UpdateItem("D:\Data2.bin", "")
            oZip2.Save("D:\Data_Archive.zip")
        End Using

This code generates "Unable to move the replacement file to the file to be replaced. The file to be replaced has retained its original name.". The temp directory is set correctly. I am I overlooking something simple, or should I be going about this a different way? Any suggestions are welcome.

Jon
Coordinator
Jun 11, 2008 at 4:51 PM
Hey JonBoy,

Yes, this may be a bug.

I think the error you are getting is telling you that that the original zip file "D:\Data_Archive.zip"  is not being overwritten.
The documentation for the Save("filename") method says:  "Existing files will be overwritten with great prejudice."  It seems this is not the actual behavior.

But in addition to the bug, I think there is some confusion on your part regarding how to use the library.

Your second stanza opens a new ZipFile, a totally new zipfile.  The no-argument constructor you use (New ZipFile)  says - this is going to be a new zip file.
So in fact you are not Updating any entries in an existing zipfile. You are creating a totally new, independent zip file.
And by calling UpdateItem() on that totally new zipfile, you are adding the item to the zipfile.

Ok, then you try to save into a zip archive that already exists.   The file is not being overwritten.  This is the bug.  

if you want to update a zip file you would do something like this: 

        Using oZip2 As New ZipFile  'Start adding new files to a new zip file.
            oZip.AddItem("D:\Data.bin", "")
            oZip2.Save("D:\Data_Archive.zip")
        End Using

        Using oZip As New ZipFile("D:\Data_Archive.zip") 'Open the existing
            oZip2.UpdateItem("D:\Data2.bin", "")
            oZip.Save()
        End Using

Or, another option is like this:

        Using oZip2 As New ZipFile("D:\Data_Archive.zip")  'open a new or existing archive.
            oZip.UpdateItem("D:\Data.bin", "")
            oZip2.Save("D:\Data_Archive.zip")
        End Using

        Using oZip As New ZipFile("D:\Data_Archive.zip") 'open the existing archive
            oZip2.UpdateItem("D:\Data2.bin", "")
            oZip.Save()
        End Using

Coordinator
Jun 11, 2008 at 4:53 PM
Edited Jun 11, 2008 at 4:59 PM
Ahh, the bug I think has to do with using a different volume for the temp file, versus the final file.

This is workitem 5284

http://www.codeplex.com/DotNetZip/WorkItem/View.aspx?WorkItemId=5284
Jun 11, 2008 at 5:41 PM
Thanks for the quick response Cheeso.

I did notice that line in the documentation as well, but it seemed to go against what I found in discussion http://www.codeplex.com/DotNetZip/Thread/View.aspx?ThreadId=28509 when the functionality was added.

The clarification on the ctors and .save method for new vs. existing archives makes sense now. Thanks for creating the work item for the .temp file and archive being on a different directory.


Coordinator
Jun 11, 2008 at 6:56 PM
I did notice that line in the documentation as well, but it seemed to go against what I found in discussion http://www.codeplex.com/DotNetZip/Thread/View.aspx?ThreadId=28509 when the functionality was added.

We seem to have a little foncusion here.
The discussion
http://www.codeplex.com/DotNetZip/Thread/View.aspx?ThreadId=28509

is referring to updating entries within a zipfile.  The line in the documentation you are commenting on  - I think you mean the part that says -  "Existing files will be overwritten with great prejudice."   deals with updating a zip archive on the disk

They are related but not quite the same thing.  What I mean is -
a common scenario will be to read in an existing ZipFile, then update items in the zip file, then save the zipfile to the disk.   I think this is what you were trying to do, JonBoy.
The discussion at 28509 said we have now added UpdateFile() and UpdateItem() as methods on the ZipFile class. That takes care of "updating items in the zip file".  The thing you are doing is saving the updated file, back to the same place.   This is the part that is covered by  "Existing files will be overwritten with great prejudice."   

Except there was a bug dealing with multiple volumes (C:\ versus d:\).

As I said I put a fix into the source for this.  If you want to workaround the problem with an existing binary, set the TempFileFolder to be on a disk that is the same as the disk you are saving your ZipFile to.  Eg, d:\temp.  If you want the fix, you can build the latest source yourself or wait for a new binary from me.

Make sense?
Jun 11, 2008 at 7:22 PM
I understood the different volume issue from your previous response (I changed my files\directories to C: and verified that). Already copied down the latest source.

>> The thing you are doing is saving the updated file, back to the same place.   This is the part that is covered by  "Existing files will be overwritten with great prejudice." 
Roger that Capt! Understood.