Tested on a Solaris 10 box, tar with --create --listed-incremental uses (as shown by truss) the old-fashioned method for getting the cwd: get .'s inum, find it among all of ..'s entries, and repeat.
That method was always known to fail if some ancestral directory lacked read permission. On ZFS filesystems there is another reason for the method to fail. Under a ZFS mountpoint is a .zfs directory that is only there if you are looking for it (does not show up in a readdir): $ ls .z* # nobody here but us chickens .z*: No such file or directory $ cd .zfs # oh, sorry, you mean ME? $ Because of that, if tar is run beneath the .zfs directory (for example, in a ZFS snapshot, a reasonable application) the old algorithm for getting the cwd fails. Instead of getting EPERM as in the case of an unreadable directory, it simply reaches the point where . is the .zfs directory and reads all of .. without finding the match, proceeding to a segfault. There could be discussion of what the bug really is. For one thing, why does --listed-incremental even want to get the cwd? It seems to put only relative paths in the snar file. IIRC one of the goals for GNU tools was to eliminate non-inherent limitations, and there seem to be enough situations in *n*x where absolutizing paths leads to problems when the operation is completely well-defined and feasible with relative paths that "one should not absolutize without necessity" seems like a sound principle. But allowing that there might be a reason for --listed-incremental to need the cwd, it's common these days for the OS to provide getcwd as a syscall to avoid the failure modes of the old algorithm. Solaris 10 does (this actually isn't stated in the man page, which has not moved from section 3C to 2, but is clear in a truss). So it's not obvious why --listed-incremental would cause the old algorithm to be used on an OS that provides a working syscall implementation. Is a new autoconf test required? ZFS users can work around the problem by doing a loopback mount of the desired snapshot to some other location that isn't beneath the invisible .zfs directory, and running tar from there. Chapman Flack Dept. of Mathematics Purdue University
