>Date: Wed, 15 Aug 2007 19:50:25 +0200
>From: Joerg.Schilling at fokus.fraunhofer.de (Joerg Schilling)
>
... ... ...
>
>If interface stability is really important for OpenSolaris, then tar(1),
>cpio(1) and pax(1) cannot implement an incomatible way of handling the -/
>option. The option -/ (introduced in 1994) has the following meaning:
>
> -/ Don't strip leading slashes from file names when
> extracting an archive. Tar archives containing abso-
> lute pathnames are usually a bad idea. With other tar
> implementations, they may possibly never be extracted
> without clobbering existing files. Star for that rea-
> son, by default strips leading slashes from filenames
> when in extract mode. As it may be impossible to
> create an archive where leading slashes have been
> stripped while retaining correct path names, star does
> not strip leading slashes in create mode.
J?rg,
The only way these four cases (PSARC/2007/459 [cpio, pax, &
tar], 423 [compress, cp, pack, uncompress, & unpack], 410 [chmod], and
394 [ls]) create any incompatibility with star is if star is intended
to replace cpio, pax, or tar. When you chose to add -/ to star, you
guaranteed that star could NEVER replace tar, cpio, or pax in /usr/bin
(which supply behavior conforming to SVID3, XPG3, XPG4, SUS, SUSv2,
SUSv3 and all of the POSIX standards). Stripping leading slashes from
absolute pathnames (by default) as files are extracted from archives
violates standards requirements for all of these utilities.
Since star cannot replace tar, cpio, or pax without changing
the default behavior of star and the meaning of the -/ option as it has
been defined by star for the last 13 years, I see no reason why -% and
-/ cannot behave as described in these four PSARC cases without causing
any incompatibilities to the existing star nor to possible future star
enhancements described in PSARC/2004/480.
- Don
>
>J?rg
