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

Add support for storing raw data #224

Open
cperciva opened this issue Dec 26, 2016 · 0 comments
Open

Add support for storing raw data #224

cperciva opened this issue Dec 26, 2016 · 0 comments
Assignees

Comments

@cperciva
Copy link
Member

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).

@cperciva cperciva self-assigned this Dec 26, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

1 participant