Date: Mon, 7 Jun 2004 15:48:20 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: Tim Kientzle <tim@kientzle.com> Cc: Nate Lawson <nate@root.org> Subject: Re: cvs commit: src/lib/libarchive archive_read_extract.c Message-ID: <20040607150924.L11542@gamplex.bde.org> In-Reply-To: <40C3D977.3010900@kientzle.com> References: <20040605053115.45AE416A585@hub.freebsd.org> <20040605000326.B54841@root.org> <20040606143616.W2060@gamplex.bde.org> <40C2E401.5010400@freebsd.org> <20040606195023.M3004@gamplex.bde.org> <40C3D977.3010900@kientzle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 6 Jun 2004, Tim Kientzle wrote: > Bruce Evans wrote: > > On Sun, 6 Jun 2004, Tim Kientzle wrote: > >>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: > ... > That is, archives written to regular files are not > padded unless you explicitly specify a block size. > ... > (I just realized that padding when -b is explicitly > specified is broken in -CURRENT; I'll commit the > fix for that shortly.) I only really care about this case. Different behaviour for regular files in the default case is just surprising. > >>>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. The behaviour actually seems to be semi-random. When I first tried it yesterday. bsdtar followed the symlink. It stopped following the symlink before I wrote the mail. Today with up to date libachive and tar, it started with not following the symlink, then switched to following it after I tried putting the symlink in a diferent directory (/var/tmp/foo ->/tmp instead of /tmp/foo ->/tmp) and then moved back to it being in /tmp. Of course, I can't get it to fail again. I remember one sign of the problem in truss output: when bsdtar didn't follow the symlink, it exited soon after __acl_mumble() returned ELOOP (it was silent about this error and exited with status 0). The file system doesn't have acls, and all the acl calls return EOPNOTSUPP when bsdtar works correctly. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040607150924.L11542>