Deletion of zip entries in-place

[rushiiMachine]

Rewriting will take way too long on mobile devices, so deleting in-place would be appreciated.

[zamazan4ik]

Do you have some benchmarks and some measurements? It will be much easier to us compare current version of the library and possibly improved one. Thanks in advance!

[Plecra]

I have a good sense of the performance this will gain us :) It'll mostly come down to literal throughput - deleting files in place can be done by tweaking their header a little, but right now the library forces users to rewrite the entire archive to achieve the same thing.

There shouldn't be much in the way of a ZipWriter::remove_file API which would be able to ensure the file isn't added to the central directory, which can be done whenever either of us has an opportunity

[KOLANICH]

I personally don't care about mobile devices, but I need to replace small metadata files within big (several GiBs) archives. It's better to do it without copying.

Also copying unnecessarily burns SSD

[Plecra]

Any PRs to implement this would be readily merged! 😄 ZIP Archives source of truth belongs in the central directory, so all we need to do to "delete" a file is to remove it from there. Luckily, this is the last step done by our ZipWriter::finish. You'll need to remove all the metadata about a file that is deleted. I'd expect to be able to do this after the changes:

let mut archive = ZipWriter::new_append(my_archive)?;
// WARNING: content of the file remains. This is NOT SECURE
archive.remove_file("old_info.txt"); // maybe not this exact API! use your judgement for what's best
archive.finish()?;
// opening `my_archive` in a zip archiver wont show old_info any more

[rushiiMachine]

I did a very hacky solution that involved adding a trait for truncating
since it isnt a public API in my use case it was acceptable but for this definitely not

https://github.com/DiamondMiner88/zip-android/blob/d6a53168bf1c23f3391008d2a955cdb16668e714/zip/src/write.rs#L857

[Plecra]

ohhohoho nooooooo 😆 that's amazing! I like your solutions for actually getting rid of the content. I suppose the API I was suggesting ought to be forget_file, as opposed to an implementation that will remove it more thoroughly.

I definitely think we should add the fill_void though! It can go in an extra method, and probably clear out more of the metadata in the local store

[baloo]

@Plecra I'd love to put some work to get @rushiiMachine 's implementation merged.

I'm just wondering about the warning in the readme saying there wouldn't be new features merged.
zip-rs/zip-old@2be9ae8
But your comment earlier (https://github.com/zip-rs/zip/issues/283#issuecomment-1314255582) seems to indicate you would merge a PR?
(I just prefer asking before putting some work) Nevermind: it's easier to get a branch with just zip changes anyway. See zip-rs/zip-old#334

[Pr0methean]

https://crates.io/crates/zip_next gives ZipWriter an abort_file() method which, if called when not is_writing_file(), will delete the most recently added file (or, if run on a ZipWriter freshly created with new_append(), the file with the last CDR entry).

[Plecra]

I love that! It makes so much sense in the streaming writer.