James Carlson <james.d.carlson at sun.com> wrote: I am glad to see that you try to start a formal and techical based discussion.
> Joseph Kowalski writes: > > I *think* Joerg's position was that star should be /usr/bin/star (as > > opposed to /usr/sfw/bin/star), but *not* a replacement for tar. > > Even as /usr/bin/star, I don't see a reason to overturn 2007/394. > That case noted that there was _no_ common flag available for the work > described in section 4.1 of 2007/315 and thus selected '-/' and '-%' > for its work. While it is bad practice not to use a uniform interface for many tools implementing the same feature (and this is why I did already send mail for the ls(1) call in June), there is no real conflict for "star". There is however a conflict with the interfaces that have been build just to create Solaris compatibility. This case breaks compatibility with these interfaces. > When I reviewed 2007/315, I didn't know that it involved a cascade of > new options for those utilities. I expected the utilities to change, > but not in the command line. This series of cases has been a > surprise. > > Personally, I'd like to do in both '@' and '/' as modifiers for > programs like tar and cp. It'd make more sense to me if these > utilities always copied all of the information available when both > source and target support the operation rather than growing new > hairball options every time we tweak a file system somewhere. The cpio philosophy would not need in extract mode as cpio by default extracts permission (although not time stamps). You could create a new archive format name that includes support for including these information in create mode. If you did not do this, you would get into problems when trying to exchange data with other platforms. The correct way of implementing these features in pax would be either by extending the supported parameter to the -p option or by using the -o option. When extracting an archive that contains the extensions, -pe should extract all available data. If the -o option would be used, it would be something like: -o xattr See: http://www.opengroup.org/onlinepubs/009695399/utilities/pax.html The tar command by default behaves similar to cpio, excapt that you may switch off to extract some of the properties. This ARC case is not really aligned with the POSIX philosohy of the commands. BTW: Don should know that this arc case is in conflict with the POSIX philosohy because it tries to implement functionality in a way that is not aligned with the way POSIX defines extensions. > That might just be me, though. > > > There was supposed to be a "statement of intent" that star would > > eventually replace tar. > > > > Had this happened, then it is clear that conflicts between tar and > > tar would have been addressed. > > Yes, but if that had happened, we would have said: the project > proposing this new tar implementation came later to the ARC (and into > OpenSolaris), so make it compatible with the previous projects or > explain some better way forward. OK, the proposal to use -/ came definitely after it did appear in the interfaces that have been created for compatibility with the Sun commands. > The current 'star' command appears to have some 151 separate options. > Conflicts seem likely. There is a small list, see ~ line 2450 in star.c The conflicts between /usr/bin/tar and star all have been created by Sun. The related option have been introduced into star around 1985. The conflicts did not exist before SunOS-5.x came out. > And, as Don has correctly noted, it defaults to stripping the leading > '/' from extracted files, which is helpful for security, but is both a > POSIX violation and a clearly incompatible behavior. It can't be the > default tar without changes. Don should know that there is no POSIX violation. He did not prove his claim with a pointer to the POSIX standard, judge yourself whom to believe..... J?rg -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de (uni) schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
