Open allisonkarlitskaya opened 1 month ago
Our home-brew header handling code is half decent at this point...
Another idea for how we could maybe force the tar crate to do our bidding: we could try to return an error from our read() implementation that contained the object reference. I'm not sure if it's possible to encode that in an std::io::Result, though? Those seem kinda like they're basically an errno
...
Another thing to consider here is performance: our current approach is forced to allocate the path so that it can return a TarEntry (removing itself from the stack in the process).
If we did a callback instead of returning, then we could serve pointers directly out of the tar header. If we wanted to get very fancy we could take advantage of the fact that we only ever process one splitstream inline chunk at a time and also store slice pointers to the xattr and pax longname data.
One of the following needs to happen:
tar
crate together withSplitStreamReader
. This could maybe work by:Read + Seek
onSplitStreamReader
and figure out a very clever way to avoid reading the file content of external references by usingseek()
. I'm not sure how we access the underlyingSplitStreamReader
object to check if we're at inline content or an external reference, though, without running afoul of the borrow checker...Read
implementation of&[u8]
), knowing that we'd hit an unexpected EOF if we tried to read the file data. This is probably doable, but kinda ugly.