"Garrett D'Amore" <gdamore at sun.com> wrote:
> I have since learned, from the project team, that this problem is
> primarily centered around solving issues with Live Upgrade. They are in
> a bind on timing, because they are coming up on a key deliverable date.
> Redesign of the file format, and resetting the testing that has already
> been done, would be detrimental to some key deliverables around Live
> Upgrade and Solaris 10.
If I understand the background correctly, I would guess that there only seems
to be a need for cpio -p. Is there a need to grant the ability to unpack
cpio archives that use the feature for more than one hour?
BTW: I expect the effort to change an existing implementation to my proposal
to less than 5% of the effort already spent. The changes needed for my proposal
are marginal compared to the complete effort for a correct implementation.
> Therefore, I recommend an alternate proposal, which I think might
> satisfy most of the participants here.
>
> 1) Relegate the ascii_sparse and odc_sparse arguments, and the
> associated file formats to "undocumented" status. That is, they won't
> be documented in the man pages. This way nobody should have to worry
> too much about dealing with these file formats portably. (Neither AT&T,
> nor GNU, nor star, ever needs deal with them.) These arguments and file
> formats will have "Project Private" binding.
If the result would be that possihle a cpio replacement does not need to
support the same archive format, I have no problems with this idea.
> 2) File a contract for their use by the LU (or any other projects) that
> need them. (At the same time, we should be giving advice to these
> projects that they should try to convert to use pax if possible.)
>
> 3) Anyone else looking for sparse file support should be strongly urged
> to use the existing pax (or star, if you prefer. I don't want to get
> into a debate about Sun pax vs. star vs GNU tar. Its not this case.)
>
> This would allow the project to go forward with their existing code,
> with minimal disruption to their plans, and minimal disruption to
> "documented" formats that external parties (star, GNU tar, AT&T) have to
> be prepared to accept.
I would be happy to see a single OpenSource implementation in future that
has the advantage to grant the same features regardless of the CLI being used.
pax was a result of the POSIX tar-wars that started around 1990. pax was never
really accepted by the community and the sysadmins that mostly prefer tar.
cpio seems to be preferred by people with an AT&T based UNIX background.
Solaris currently has three archiver implementations and every idea needs to
be implemented and tested three times. In the long term, it pays off to make
a change to a single star based solution.
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/private/ ftp://ftp.berlios.de/pub/schily
