The same volume can not be used as both the source and destination

Question

I'm creating split archives using the following code:

string filename = "FileName.pdf";
using (ZipFile zip = new ZipFile())
{
    zip.UseZip64WhenSaving = Zip64Option.Default;
    zip.CompressionLevel = Ionic.Zlib.CompressionLevel.Default;
    using (FileStream stream = new FileStream(temp, FileMode.Open))
    {
        zip.AddEntry(filename, stream);
        zip.MaxOutputSegmentSize = settings.AttachmentSize * (1024 * 1024);
        zip.Save(zipFileName);
    }
}

The code above generates 3 files: file.zip, file.z01 and file.z02. When I right-click that zip file and select Extract All (not using WinRAR or other zipping software to extract, just the built-in Windows zip) it gives me the following error:

The same volume can not be used as both the source and destination

What's weird is that it only happens on the first time I try to extract the files, the succeeding extractions are OK so it must be how the files were zipped in the first place.

UPDATE 1

The same thing happens even if I extract to a different folder

There have been discussions with regards to this issue on the DotNetZip Codeplex site, but it seems the issue has not been resolved yet

http://dotnetzip.codeplex.com/discussions/239172

http://dotnetzip.codeplex.com/discussions/371005

UPDATE 2

Looking at the doc for the MaxOutputSegmentSize property, it is quoted:

I don't believe Windows Explorer can extract a split archive.

There's no further explanation though as to why. I consider this to be a false-positive since as mentioned above,

it only happens on the first time I try to extract the files, the succeeding extractions are OK

I'm using Windows 8.1 64-bit.

Answer 1

First thing you'd always want to do when searching for the reason why software fails is locating the source of the error message. You do that by using Google first. Second hit (right now) is golden, somebody has decompiled Windows executables and located this specific string as resource ID #10209 in a file named zipfldr.dll with a Microsoft copyright notification.

That is an excellent match, zipfldr.dll is the shell namespace extension that Windows uses to display the content of a .zip file as though it is a folder. You can see it in Regedit.exe, navigate to HKEY_CLASSES_ROOT\CLSID\ {E88DCCE0-B7B3-11d1-A9F0-00AA0060FA31} for the primary registration. The HKEY_CLASSES_ROOT\SystemFileAssociations\ .zip\CLSID registry key associates it with a .zip file.

So you have a hard fact, it really is the Explorer extension that falls over. Exceedingly little you can do about that of course. Only remaining doubt that it might be the Zip library you use that fumbles the spanned files content and thus causes the extension to fall over. That is significantly reduced by seeing more than one library tripping this error, the odds that both Ionic and Dotnetzip have the exact same bug is rather low. Not zero, programmers do tend to have a "how did they do that" peek at other programmer's code for inspiration. The fact that this error is spurious puts the nail in the coffin, you'd expect bad zip archive content to trip an error repeatedly.

You might be able to reverse-engineer the underlying problem, you'd do so with SysInternals' Process Monitor. You'll see Explorer reading and writing files. Probably in the TEMP directory, I speculate that you'd get an error like this one if a .zip file already exists in that directory. TEMP is a very messy folder on most machines, too many programs don't clean up properly after themselves. Including zip libraries, an attractive theory not otherwise backed-up by proof :)

If that doesn't pan out then the ultimate fallback is Microsoft. They have a 1-800 telephone number where you can get support for problems with their products. I've used it several times, they always solved my problem and refunded the upfront fee. This is a Windows problem however, a product that has a billion users. You'll, at best, get a workaround, an actual software fix is exceedingly unlikely. Not entirely impossible, it has been done. But very high odds that their recommended workaround is "use a 3rd party utility like Winzip". Not what you want to hear.