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
It would be nice if, in addition to storing archives like tar, tarsnap could store arbitrary streams of data. This would allow things like " | tarsnap --raw-write" to work.
Since the stream would not have parts tagged as "tar headers" vs "tar data" and there would be no backing filesystem metadata to permit use of the chunkification cache, running "tar | tarsnap --raw-write" would be slower and less efficient than directly running tarsnap, so this would be inherently an added feature, not in any sense a replacement for existing functionality.
Some notes:
I'm not sure what to call this. -w would have been nice, to match the -r option which outputs data, but that's used to request confirmation for each action. (Theoretically we could distinguish between tarsnap -w and tarsnap -[cx] -w, but that seems prone to user error.) So maybe --raw-write? Or possibly -c --raw?
Archives need to be somehow flagged as being raw data, so that -[xt] are disabled. The obvious place to do this would be in archive metadata, but I can't see any way to do that without resulting in the archives being rejected as corrupt by earlier versions of tarsnap, and I'm not sure we want to do that. An alternative would be to put a header onto the multitape-layer data; then have -r look for and strip that header and make sure that the tar code which -[xt] uses will throw an error ("not a tar archive" or something like that).
The text was updated successfully, but these errors were encountered:
It would be nice if, in addition to storing archives like tar, tarsnap could store arbitrary streams of data. This would allow things like " | tarsnap --raw-write" to work.
Since the stream would not have parts tagged as "tar headers" vs "tar data" and there would be no backing filesystem metadata to permit use of the chunkification cache, running "tar | tarsnap --raw-write" would be slower and less efficient than directly running tarsnap, so this would be inherently an added feature, not in any sense a replacement for existing functionality.
Some notes:
I'm not sure what to call this.
-w
would have been nice, to match the-r
option which outputs data, but that's used to request confirmation for each action. (Theoretically we could distinguish betweentarsnap -w
andtarsnap -[cx] -w
, but that seems prone to user error.) So maybe--raw-write
? Or possibly-c --raw
?Archives need to be somehow flagged as being raw data, so that
-[xt]
are disabled. The obvious place to do this would be in archive metadata, but I can't see any way to do that without resulting in the archives being rejected as corrupt by earlier versions of tarsnap, and I'm not sure we want to do that. An alternative would be to put a header onto the multitape-layer data; then have-r
look for and strip that header and make sure that the tar code which-[xt]
uses will throw an error ("not a tar archive" or something like that).The text was updated successfully, but these errors were encountered: