3

I'm trying to decompress a zip file:

public string unzip(string zipFilePath, string destinationFolder)
{
    try
    {
        ZipFile.ExtractToDirectory(zipFilePath, destinationFolder);
        return destinationFolder;
    }
    catch (Exception ex)
    {
        throw ex;
    }
}

When I pass in the following value for zipFilePath:

t:\aaaaaaa aaaaaaaaaa aaaaaaaa\aaaa aaaaaa\aaaa aaaaaaaaaa aaaaaa\aaaa aaaaaa aaa.a aaaa\aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa.zip

and this destinationFolder:

C:\Users\A312\Documents\Visual Studio 2013\Projects\PDFConverterTester\PDFConverterTester_BatchGUI\bin\Debug\tempZip\466-qqqqqqqqq qqqqqqqq qqqqqq qqqq qqqqq qqqqqqqqqqq

this exception is thrown:

The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters.

When I decompress it to destinationFolder using PKZip, there is no problem.

But there is a file in the zip archive that, when unzipped, has a full path of 261 characters.

Any idea how to deal with this?

Update: My company's IT policy will not allow me to install any new software, so I'm trying to figure out how to resolve this with Windows API calls from my existing .NET 4.5 installation of Visual Studio.

sigil
  • 9,370
  • 40
  • 119
  • 199
  • Maybe this will help . https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx – Hakunamatata Dec 26 '16 at 22:57
  • Rather than circumvent the limitation, have you considered just making your destination path shorter? If you use AppData or even another folder higher up in the user home folder, I imagine you could make a workable solution without bypassing the path length restriction. Depending on what else you need to do with the files (e.g. view them in Explorer), you might be just pushing the problem down the line by forcing a path too long. – SlimsGhost Dec 28 '16 at 18:48
  • @SlimsGhost, the directory structure is pretty much non-negotiable: it's basically `\\servername\departmentFolder\projectName\subProjectName\documentCategory\archive\archiveCategory\archive1234.zip`, and then the zip file itself has a comparable number of nested folders. – sigil Dec 28 '16 at 19:37
  • 1
    @sigil Understood. Just know that if you keep the long file names, you need to be aware of the side effects for downstream operations on those files. Maybe you could flatten the hierarchy of the zip file contents? – SlimsGhost Dec 28 '16 at 22:17

2 Answers2

2

Try prepending the \\?\ prefix to your full path in order to circumvent the 260/248 character limitation:

\\?\t:\aaaaaaa aaaaaaaaaa aaaaaaaa\aaaa aaaaaa\aaaa aaaaaaaaaa aaaaaa\aaaa aaaaaa aaa.a aaaa\aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa.zip

More information can be found here: https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396

You should also use this function sparingly as it disables Windows' check for valid filenames in the file system.

silkfire
  • 24,585
  • 15
  • 82
  • 105
  • In testing this on `System.IO.File.Copy()`, I got an `Illegal characters in path` exception. Any idea why? I know it's a separate problem, and I'm happy to start a new question for it. – sigil Dec 27 '16 at 00:09
  • Yeah, you should use some of the APIs that wrap Win32 functions that bypass the character limitation. For example **Delimon.Win32.I​O** (https://gallery.technet.microsoft.com/scriptcenter/delimonwin32io-library-v40-7ff6b16c) or **ZetaLongPaths**. – silkfire Dec 27 '16 at 07:39
  • @sigil I'd recommend ZLP. To copy files you'd use this static method: `ZlpIOHelper.CopyFile(sourcePath, destinationPath, overwriteExisting)`. – silkfire Dec 27 '16 at 07:50
0

I ended up using 7zip instead, as per this answer, because it doesn't have a character limitation.

Community
  • 1
  • 1
sigil
  • 9,370
  • 40
  • 119
  • 199