Joerg Schilling writes: > > In any event, regardless of what one thinks about POSIX, the behavior > > of star is incompatible with the existing /usr/bin/tar. It's > > incompatible because star made an implementation change (forcing > > absolute paths to be relative) that historical tar did not have. You > > can certainly argue that star's behavior is "better." You can't argue > > that it's compatible. > > Sorry, but this is not an incompatible change. Is is a change that prevents > problems and all up to date tar implementations behave this way.
I've already shown how it produces different results. It does so even when invoked as "tar." I see that the odd "cf" overwrite restriction goes away when renamed to 'tar'. The other changes do not. I'm using star 1.5a74. I've also tried 1.5a80 with the same results. Perhaps there's a newer version that lacks incompatibilities. I don't know, and this really isn't the thread in which to discuss such things. Instead, this should be the topic of a future case that proposes replacing /usr/bin/tar. As pointed out repeatedly, this is _not_ that case, and that case does _not_ exist. Observe: % ls -l /opt/csw/bin/tar lrwxrwxrwx 1 root root 4 Jul 31 11:21 /opt/csw/bin/tar -> star % /opt/csw/bin/tar --version suntar: star 1.5a80 (sparc-sun-solaris2.8) Copyright (C) 1985, 88-90, 92-96, 98, 99, 2000-2007 J?rg Schilling This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. % /opt/csw/bin/tar cf foo.tar /tmp/motd /opt/csw/bin/tar: 1 blocks + 0 bytes (total of 10240 bytes = 10.00k). % /opt/csw/bin/tar xf foo.tar /tmp/motd /opt/csw/bin/tar: WARNING: skipping leading '/' on filenames. /opt/csw/bin/tar: '/tmp/motd' did not match /opt/csw/bin/tar: 1 blocks + 0 bytes (total of 10240 bytes = 10.00k). There's the first incompatibility. It fails to match files that are clearly in the archive, because it's errantly skipping over the leading '/' mark. % /opt/csw/bin/tar xf foo.tar /opt/csw/bin/tar: WARNING: skipping leading '/' on filenames. /opt/csw/bin/tar: 1 blocks + 0 bytes (total of 10240 bytes = 10.00k). % ls -l /tmp/tmp/motd -rw-r--r-- 1 carlsonj staff 720 Aug 16 11:22 /tmp/tmp/motd There's the second incompatibility. It's extracting to a different location than the one that was archived. I understand _why_ this was done and the security problems inherent in (especially) allowing root to extract absolute files from an archive. However, at the same time, this change is not compatible and _will_ break consumers that rely on the existing behavior. It's unclear to me whether the stderr spewage will break anything, but I wouldn't be surprised if it does. Most common utilities don't write to stderr unless there's actually an error. Sending success messages there is really strange. A future case that deals with replacing /usr/bin/tar will _have_ to deal with these incompatibilities in detail. -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
