cvs commit: src/lib/libarchive archive_read_extract.c
kientzle at freebsd.org
Sun Jun 6 09:30:11 GMT 2004
Bruce Evans wrote:
> On Sat, 5 Jun 2004, Tim Kientzle wrote:
>>>>+ if (stat(name, &st) == 0 && S_ISDIR(st.st_mode))
> Perhaps this or a nearby stat() should be lstat(). libarchive doesn't
> use a single lstat() (though bsdtar does).
No, this should be stat(). Otherwise, you cannot
extract through an existing symlink. (E.g., some
people need to be able to do the following:
ln -s /other/disk /usr/ports
bsdtar xf ports.tgz
Also, note that---apart from the "extract"
function---libarchive doesn't deal with stuff
on disk. It just knows how to assemble/disassemble
archives. It has very little reason to use either
stat() or lstat().
> In fact, this stuff is quite broken. After "cd /tmp; ln -s /tmp foo",
> tarring up foo[/.] gives the following misbehaviours with yesterday's
> versions of tars:
> tar cf z foo:
> only puts foo in the archive (correct)
> bsdtar cf z foo:
> same, except bsdtar seems to be too smart about padding the output
> to a block boundary for regular files, so subsequent piping of the
> file might not work
The default padding behavior for bsdtar was changed quite
a while ago to not pad regular files; are you sure you're up-to-date?
> tar cf z foo/:
> only puts foo in the archive (broken)
> bsdtar cf z foo/:
Here, bsdtar cf z foo/ does follow the symlink, which I
presume you believe to be the correct behavior?
> tar cf z foo/.:
> puts files named foo/./* in the archive (everything under /tmp except
> z). Warns about not attempting to put the archive inside itself.
> bsdtar cf z foo/.:
> same, except it silently puts a truncated copy of the archive inside
Yes, bsdtar does not yet have a check for visiting the archive
itself. I agree that this is broken.
More information about the cvs-all