3

Wehen i set the zip.MaxOutputSegmentSize high enough so there would be only one zip file it works. As soon as i limit the MaxOutputSegmentSize i get this error after one of the split files reaches its max size - when i have a value like 20MB it allways occcurs on the end of file ".z02", if the value is smaller it may also occur some file later.

If i use zip.ZipErrorAction = ZipErrorAction.Skip or .Retry i get an System.ObjectDisposedException instead.

What might be the Problem here or is this a Bug in DotNetZip Library?

ZipFile zip = new ZipFile(backupPath + "Backup.zip");
            zip.MaxOutputSegmentSize = maxSize;
            //zip.TempFileFolder = @"D:\Backup\Temp"; //seems not to make any difference

            zip.Comment = "Backup created at " + System.DateTime.Now.ToString("G");
            zip.AddFile(dbBackup.FullName,"Database");
            zip.AddDirectory(physicalAppPath,"Application");

           zip.AddDirectory(mailArchivePath,"MailArchive");
           zip.Save(); //Exception occurs here

StackTrace:

bei System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
bei System.IO.File.Move(String sourceFileName, String destFileName)
bei Ionic.Zip.ZipSegmentedStream.TruncateBackward(UInt32 diskNumber, Int64 offset)
bei Ionic.Zip.ZipEntry.Write(Stream s)
bei Ionic.Zip.ZipFile.Save()
bei MyProject.Configuration.Backup.BackupLogic.Backup(Boolean monthly) in D:\projects\MyProject.Configuration\Backup\BackupLogic.cs:Zeile 100.
bei MyProject.Configuration.Backup.BackupLogic.ScheduledBackup() in D:\projects\MyProject.Configuration\Backup\BackupLogic.cs:Zeile 42.
bei MyProject.Configuration.BackupTimer.CreateThread(Object parameters) in D:\projects\MyProject.Configuration\BackupTimer.cs:Zeile 60.
bei System.Threading.ExecutionContext.runTryCode(Object userData)
bei System.Runtime.CompilerServices.RuntimeHelpers.ExecuteCodeWithGuaranteedCleanup(TryCode code, CleanupCode backoutCode, Object userData)
bei System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean ignoreSyncCtx)
bei System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
bei System.Threading.ThreadHelper.ThreadStart(Object obj)

Exception and StackTrace for using ZipErrorAction.Skip:

ObjectDisposed Exception was unhandled: Auf eine geschlossene Datei kann nicht zugegriffen werden. (Could not access an closed file)

bei System.IO.FileStream.get_Position()
bei Ionic.Zip.ZipEntry.Write(Stream s)
bei Ionic.Zip.ZipFile.Save()
...

Process Monitor with filter on the Destination Folder shows nothing suspicious: (in this case 3 split files were created, then the exception occured)

12:35:25.6312905 PM w3wp.exe    5380    CreateFile  D:\Backup   SUCCESS Desired Access: Write Data/Add File, Synchronize, Disposition: Open, Options: , Attributes: n/a, ShareMode: Read, Write, AllocationSize: n/a, Impersonating: NT-AUTORITÄT\IUSR, OpenResult: Opened
12:35:25.6319249 PM w3wp.exe    5380    CloseFile   D:\Backup   SUCCESS 
12:35:27.7507327 PM w3wp.exe    5380    CreateFile  D:\Backup   SUCCESS Desired Access: Write Data/Add File, Synchronize, Disposition: Open, Options: , Attributes: n/a, ShareMode: Read, Write, AllocationSize: n/a, Impersonating: NT-AUTORITÄT\IUSR, OpenResult: Opened
12:35:27.7511904 PM w3wp.exe    5380    CloseFile   D:\Backup   SUCCESS 
12:35:32.9936509 PM w3wp.exe    5380    CreateFile  D:\Backup   SUCCESS Desired Access: Write Data/Add File, Synchronize, Disposition: Open, Options: , Attributes: n/a, ShareMode: Read, Write, AllocationSize: n/a, Impersonating: NT-AUTORITÄT\IUSR, OpenResult: Opened
12:35:32.9941529 PM w3wp.exe    5380    CloseFile   D:\Backup   SUCCESS
ThomasK
  • 41
  • 1
  • 6
  • There was a bug in v1.9.1.5 of DotNetZip, relating to segmented archives. What version are you using? – Cheeso Aug 23 '11 at 00:11
  • It is the newest 1.9.1.8 "This is the Developer's Kit package for DotNetZip v1.9. This package was packed Sat-08-06-2011-215945.06." – ThomasK Aug 23 '11 at 07:27
  • the unauthorizedaccessexception is of the File.Move method and could mean the file being written to already exists and is already in use (maybe even by your own application) or read-only or privileged otherwise or you don't have the right to create or delete files in that directory. hard to tell what went wrong here but I suppose the DotNetZip community could help you or you could try and watch the file operations in that folder using a SysInternals Suite tool to see what's going on while you're debugging. a stacktrace for the objectdisposedexception might also tell us something, post it. – mtijn Aug 23 '11 at 10:30
  • The Folder i create the zip file in is empty and nothing besides the zip.save() method works on it. So somehow the DotNetZip should create this write issue by itself. – ThomasK Aug 23 '11 at 11:20
  • I added the other stacktrace - thx – ThomasK Aug 23 '11 at 11:26
  • Process Monitor from Sysinternals Suite shows nothing suspicous, added its result... – ThomasK Aug 24 '11 at 10:45
  • just some more steps before I give up: can you reproduce this on other systems or in other folders on the same system? is the target folder compressed or encrypted? does NT-AUTORITÄT\IUSR have enough modification rights on the folder? do large single files zip ok? is there enough space on drive D? – mtijn Aug 24 '11 at 11:14
  • The Problem was that there are gzip files (.gz with password) in one Folder - see my Answer. Thx for your help! – ThomasK Aug 24 '11 at 13:42

1 Answers1

1

The Problem was that there are gzip files (.gz with password) in one Folder - it seems that DotNetZip can not split those (7zip can). So as soon as it reaches the end of a .zip file filled with those gzip files the exception occurs.

I used now a workaround so i cycle all my files, calc the total size and create single (not splitted) zip files each time i reach my max size.

The Problem (Bug?) for DotNetZip remains.

ThomasK
  • 41
  • 1
  • 6