ArchiveFileModel does not expose file metadata
weltkante opened this issue · 3 comments
As mentioned in issue #12 the current implementation of ArchiveFileModelMetadataReader is incomplete. It stores the file metadata while reading it but does not build the corresponding ArchiveFileModel to expose it.
Updated the nuget package to include a prototype for the ArchiveFileModel implementation. The mapping between streams and files may need improvement.
The current concept for the ArchiveFileModel builds a tree of folders and files to allow hierarchical display/navigation. The concept was missing a mapping between file metadata and their streams and relied on the caller doing the counting to associate streams with files.
I've added a simple index-based mapping on the ArchiveFileModel to map from stream to file metadata, and I've extended the ArchivedFile class to store the stream index.
It is still unclear how to expose the advanced features of the 7z format (in particular deletion markers). In the current implementation deletion markers are not exposed but they are resolved internally in case the file is added and then deleted in the same archive (but I think this is a corner case which is not expected from normal archives, since archives are not updated incrementally but always rebuilt from scratch, so a filename would normally only appear once).
While going through the ArchiveFileModel I also noticed the offset metadata was not included in the previous API. I've added it for now, but I don't exactly remember what it meant. I think it was related to sparse files and meant that the compressed content should be placed in the middle of the file instead of at the beginning. Further research in the original sourcecode is required to determine the usage of that offset metadata field.
The file metadata should also be exposed as a flat list so one can iterate over all files without having to traverse the hierarchy. This is required to properly extract all files, not just those with content.