cvs commit: src/lib/libarchive archive_read_extract.c

[Tim Kientzle]

Bruce Evans wrote:
> On Sun, 6 Jun 2004, Tim Kientzle wrote:
>>Bruce Evans wrote:
>>
>>>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?
> 
> Yes; not padding is a bug and the above says that I have it.

I've discussed padding issues with a number of people, and
the following behavior seems acceptable to most.  If you have
reasons to disagree, please let me know:

$ bsdtar cf z foo && ls -l z
-rw-r--r--  1 tim  wheel  1536 Jun  6 17:16 z
$ bsdtar cfb z 20 foo && ls -l z
-rw-r--r--  1 tim  wheel  10240 Jun  6 17:16 z
$ bsdtar cf - foo | cat > z && ls -l z
-rw-r--r--  1 tim  wheel  10240 Jun  6 17:17 z

That is, archives written to regular files are not
padded unless you explicitly specify a block size.
Archives written to pipes (or block or char devices) are
padded.  The same behavior applies to archives compressed
via 'z', 'j', or 'y' options, as demonstrated here:

$ bsdtar czf z foo && ls -l z
-rw-r--r--  1 tim  wheel  126 Jun  6 17:25 z
$ bsdtar czfb z 20 foo && ls -l z
-rw-r--r--  1 tim  wheel  10240 Jun  6 17:25 z
$ bsdtar czf - foo | cat > z && ls -l z
-rw-r--r--  1 tim  wheel  10240 Jun  6 17:25 z

(I just realized that padding when -b is explicitly
specified is broken in -CURRENT; I'll commit the
fix for that shortly.)

>>>bsdtar cf z foo/:
>>
>>Here, bsdtar cf z foo/  does follow the symlink, which I
>>presume you believe to be the correct behavior?
> 
> Yes.  foo/ is not a symlink (the slash forces folling the symlink) in the
> kernel, so it should do so in utilities too.

Good, then you agree that bsdtar does the right thing
in this example.

Tim