Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature request: delete a file #22

Open
adsilva-ivre opened this issue Apr 1, 2024 · 1 comment
Open

Feature request: delete a file #22

adsilva-ivre opened this issue Apr 1, 2024 · 1 comment
Labels
💡 Enhancement New feature or request ⏳ Epic Long (and difficult) task 📚 Specification This need a change in Arx format itself 💰️ Sponsor appreciated This issue is open to financial support if you want it to be implemented

Comments

@adsilva-ivre
Copy link

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🤔

@mgautierfr
Copy link
Member

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.

@mgautierfr mgautierfr added the 💡 Enhancement New feature or request label Aug 28, 2024
@mgautierfr mgautierfr added ⏳ Epic Long (and difficult) task 📚 Specification This need a change in Arx format itself 💰️ Sponsor appreciated This issue is open to financial support if you want it to be implemented labels Nov 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
💡 Enhancement New feature or request ⏳ Epic Long (and difficult) task 📚 Specification This need a change in Arx format itself 💰️ Sponsor appreciated This issue is open to financial support if you want it to be implemented
Projects
None yet
Development

No branches or pull requests

2 participants