mirror of
https://github.com/vbatts/tar-split.git
synced 2024-12-19 20:06:30 +00:00
tar/asm: adding thoughts on concerns
This commit is contained in:
parent
081c5b9feb
commit
6814b938af
1 changed files with 14 additions and 5 deletions
|
@ -24,10 +24,19 @@ path would be identical.
|
||||||
Thoughts
|
Thoughts
|
||||||
--------
|
--------
|
||||||
|
|
||||||
While the initial implementation is based on a relative path, I'm thinking the
|
Have a look-aside directory or storage. This way when a clobbering record is
|
||||||
next step is to have something like a FileGetter interface, of which a path
|
encountered from the tar stream, then the payload of the prior/existing file is
|
||||||
based getter is just one type.
|
stored to the CAS. This way the clobbering record's file payload can be
|
||||||
|
extracted, but we'll have preserved the payload needed to reassemble a precise
|
||||||
|
tar archive.
|
||||||
|
|
||||||
Then you could pass a path based Getter and an Unpacker, and receive a
|
clobbered/path/to/file.[0-N]
|
||||||
io.Reader that is your tar stream.
|
|
||||||
|
*alternatively*
|
||||||
|
|
||||||
|
We could just _not_ support tar streams that have clobbering file paths.
|
||||||
|
Appending records to the archive is not incredibly common, and doesn't happen
|
||||||
|
by default for most implementations. Not supporting them wouldn't be a
|
||||||
|
security concern either, as if it did occur, we would reassemble an archive
|
||||||
|
that doesn't validate signature/checksum, so it shouldn't be trusted anyway.
|
||||||
|
|
||||||
|
|
Loading…
Reference in a new issue