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. Entry
s 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" Entry
s 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.