You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
What most formats don't even care to solve is how to remove files from an archive efficiently without recreating the whole archive again. With concepts like defragmenting unused space etc.
Is this something this project could target or this out of scope🤔
The text was updated successfully, but these errors were encountered:
Deleting a content is not so different of changing a content...
Jubako containers (and so Arx archives) are not especially designed to be modified. But the way Jubako is designed, we can consider archive modification. There are several way in which a Jubako container can be modified (none of them are implemented), depending of "how much" we want to change(or delete) the content:
Rewrite the directory. The directory is the "list" of entries, with metadata, pointing to data. It is pretty small and could be rewritten quite easily. If you remove an entry from the directory, the file would be "removed". However, the actual data would still be there (but not easily accessible).
Update the content. On top of modifying the directory, you may want to change (or mask) the content itself. If the content is not compressed, we could simply write \0 bytes on it. If the content is compressed, we may have to decompress the cluster containing the content, mask the content with \0 and compress again the cluster (hopping the new compressed size is smaller than the older). The data would be removed, the space would be lost. We could mark this space free for use for other update but there is no data structure for this.
Remove the content. Here we would have to move bytes after the removed content to keep everything compacted. No new compression would be needed and it would be mostly a memmove, but still a (dumb) rewrite of the archive.
But note that the two last option can be destructive. Contents are stored in packs and packs can be shared between archives (think about incremental backup). Changing a content pack means also changing its identifier and other archives may suddenly seen their content pack disappear because we have change the content pack of the archive. So we would have to do this pretty carefully.
Is this something this project could target or this out of scope
This is somehow planed. I still don't know the extend to which, but planed.
What most formats don't even care to solve is how to remove files from an archive efficiently without recreating the whole archive again. With concepts like defragmenting unused space etc.
Is this something this project could target or this out of scope🤔
The text was updated successfully, but these errors were encountered: