Date: Sun, 06 Jun 2004 19:56:55 -0700 From: Tim Kientzle <tim@kientzle.com> To: Bruce Evans <bde@zeta.org.au> Cc: Nate Lawson <nate@root.org> Subject: Re: cvs commit: src/lib/libarchive archive_read_extract.c Message-ID: <40C3D977.3010900@kientzle.com> In-Reply-To: <20040606195023.M3004@gamplex.bde.org> References: <20040605053115.45AE416A585@hub.freebsd.org> <20040605000326.B54841@root.org> <40C22518.6060406@kientzle.com> <20040606143616.W2060@gamplex.bde.org> <40C2E401.5010400@freebsd.org> <20040606195023.M3004@gamplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?40C3D977.3010900>