On 07/14/2010 10:52 PM, Rubin Bennett wrote: > I believe in that case (where you're trying to specify a file, but the > parent directories don't exist) then Brett's post is exactly correct. I > suppose tar could check each directory in the structure and if it > doesn't exist, then extract it, but that would require endless rewinding > in the archive. Remember that tar is the Tape ARchiver. When you look > in a tar archive for a specific file, it runs through the 'tape' until > it finds the *file* (or directory) you specified on the command line, > ignoring all the entries it finds until it finds what you were looking > for.
I don't see why this couldn't be done in a single pass. Tar also works from pipes which are always single pass. > Once it finds the file, it extracts it, and applies the permissions that > are encoded in the archive *for that file*. It doesn't search for the > parent directories on the way, unless you explicitly specify them on the > command line: You forgot to post the command that doesn't work. It was the obvious one: # tar xf test.tar a a/b a/b/c a/b/c/d tar: a/b: Not found in archive tar: a/b/c: Not found in archive tar: a/b/c/d: Not found in archive tar: Exiting with failure status due to previous errors > That command sets the permissions correctly but throws an error. You are right, the first time I did this I thought it just failed, but it actually does pull it out with the correct metadata. This seems like a genuine bug. > This > command, however, works with no errors, so it has to be an issue with > the order in which the files are archived: > tar xvf test.tar a/b/c/d a/b/c a/b Good call. That works. Who would have guessed you need to call out the members in reverse order? I'm surprised that GNU tar still has issues like that. # tar xf test.tar a/b/c/d a/b/c a/b a can-d:/tmp/test# tree -u . ├── [backup ] a │ └── [games ] b │ └── [news ] c │ └── [uucp ] d └── [root ] test.tar > The heart of the problem is that going back through the archive is > expensive - it takes a long time, and in an actual tape scenario would > unnecessarily wear the tape out, and take hours and hours as it went > back looking for each parent directory. Maybe there is a practical issue, but I don't see it. It doesn't sound like you think this is a bug, good to know. Thanks for your insight. -- Anthony Carrico
signature.asc
Description: OpenPGP digital signature
