cvs commit: src/lib/libarchive archive_read_extract.c

[Tim Kientzle]

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/:
>     same

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

Yes, bsdtar does not yet have a check for visiting the archive
itself.  I agree that this is broken.

Tim