Parent Directory Extraction Management
mredig opened this issue · 3 comments
I was thinking about making a contribution to provide parent directory management within Archive itself, instead of just when using the FileManager extension.
Basically, I envision adding a parentDirectory: String? property to Archive that would be utilized in both extraction and compression.
When opening an Archive in .read mode, it would parse the contents and determine if there's a parent directory and, if so, populate the value. During extraction, you'd have the option to include or omit the parent directory. Entrys provided from the Archive could either reflect this value in their path or have an additional pathFromParent property.
When opening an Archive in .create or .update modes, it would either append or ignore the parent directory as appropriate when adding content.
Is there interest for this? Time permitting, I would contribute this myself, but would want to make sure the time invested would be worth it.
Hi Michael,
Archive implements a subset of the ZIP specification and only contains low-level code that's required to archive/unarchive from/to the file system. All convenience/helper code is implemented in the FileManager extension or can be customized by API users in the closure-based Archive reading/writing methods.
Since the ZIP specification also doesn't outline a concept of hierarchy/parent-child relationships at all (e.g. .file entries can implicitly create directory trees, .directory entries are optional, ...), I'd prefer to keep all hierarchy related stuff in the extension.
Do you have a specific use case that'd benefit from having the parent directory handling in the Archive type?
Do you have a specific use case that'd benefit from having the parent directory handling in the Archive type?
Yes - that's where the idea comes from. :)
I have a need to inspect individual "root level" Entrys within an Archive that is agnostic to whether there's a parent directory or not (as in, if there is a parent directory, it needs to treat the parent directory contents as if they are in the root) without extracting the entire contents first.
Since the ZIP specification also doesn't outline a concept of hierarchy/parent-child relationships at all (e.g. .file entries can implicitly create directory trees, .directory entries are optional, ...), I'd prefer to keep all hierarchy related stuff in the extension.
What if it was done on an Archive extension, or even a second library in the Swift Package? I think there would need to be some minimal support in the base class, but the majority of it could be external, in a Conveniences package.
I think there would need to be some minimal support in the base class, ...
The behavior you are describing in your initial comment can be implemented with the existing extract/addEntry methods outside of the library without any changes to Archive - you have access to .path and the read/write closures allow you to freely choose what happens with the extracted/added entry. Or am I missing something?
I'd prefer to keep the core API surface area small but provide extensible methods (like the existing, closure-based read/write helpers) for API consumers.