This project is read-only.

Confused by ZipFile.AddFiles preserveDirHierarchy and directoryPathInArchive arguments

Aug 11, 2011 at 10:03 PM

preserveDirHierarchy and directoryPathInArchive seem very very similar exception one is a bool, and the other is a string.

the bool lets me decide to have the full directory hierarchy preserved in the archive as an on off switch, which is nice.

the string lets me also turn this off and on by passing an empty string or null, but also allows for me to create a path that all files will go into.

It seems that the bool is not required, as (preserveDirHierarchy = true) is equivalent to (directoryPathInArchive = null) and (preserveDirHierarchy = false) is equivalent to (directoryPathInArchive = string.Empty). But if you want to use the bool you MUST provide the directoryPathInArchive which seems extra odd.

If I am missing something let me know if the bool does something extra or different some how, and if so why can't it be rolled into the null and empty string options of the string to simplify? 

Aug 11, 2011 at 10:07 PM
Edited Aug 11, 2011 at 10:08 PM

Think of the directoryPathInArchive as a "root" or base directory used in the archive for the files that get added.  The hierarchy of files found in the filesystem will be placed, with the hierarchy intact, starting at that root in the archive.

This happens when preserveDirHierarchy is not present or is true.  preserveDirHierarchy, when false, says "when adding files into the archive, flatten the hierarchy of files found in the filesystem".  But the flattened set of files would still go in the root as specified in directoryPathInArchive.

Aug 11, 2011 at 10:09 PM

Ahh that makes perfect sense now.  I just do seem to get the same understanding when reading the docs for those two values.  May just be my brain miss-firing. thanks for clarification. 

Aug 11, 2011 at 10:28 PM

I just checked the documentation and it's not as clearly written as it could be.

Aug 11, 2011 at 11:49 PM

On a related note is there a reason that addSelectedFiles doesn't have an option for perserveDirHierarchy?   I can use DirectoryInfo to GetFiles by a criteria and then pass all the found files to ZipFile.AddFiles and give it the preserveDirHierarchy and directoryPathInArchive. I just cannot do it in a single line using the ZipFile.addSelectedFiles. Is this an oversight or is there a good reason that this shouldn't be done even in the two line approach?

Out of curiosity, I noticed in your source you created your own FileSelector class for finding files by a criteria, and was wondering if you created this due to issues with DirectoryInfo.GetFiles(string searchPattern, SearchOption searchOption) back in .Net 2.0 days when it was first introduced, or if you where doing this back in the .Net 1.1 days and didn't have an alternative?  This is more of a history lesson for me than anything, and also to know if you found performance issues or bugs in using DirectoryInfo.  If it is more of the .Net 1.1 days have you every compared performance between yours and Microsoft's?

Aug 12, 2011 at 12:19 AM

The FileSelector accepts criteria that are not supported by the searchPattern in the DirectoryInfo.GetFiles() method.  That's why I created it.

I'm not sure why I didn't add a preserveDirHier on AddSelectedFiles.