Don Cragun writes: > >If there are, then should we be deliberately incompatible? > > The star and the recent AT&T pax archivers encode sparse files using > ustar/pax format archives. The project team has not seen any other > attempt to encode sparse files using cpio format.
That's the part I wanted to hear: that the project team had looked for other implementations and found none. I'm satisfied with that. Garrett D'Amore writes: > Given these limitations, I wonder if it makes sense to mark these > options and the file format Uncomitted. That doesn't make sense to me. The whole point of "Uncommitted" is that you believe you'll make changes in the future and thus need to warn people away. Given the limitations, what changes would we make here in the future? > (Maybe you did in the original, > I don't recall.) We have little other way that I can think of to > politely steer customers away from this and towards something that is > free from the limitations. (Well, there is Committed Obsolete, I > suppose....) "Committed Obsolete" seems more accurate, but probably not really necessary. Don Cragun writes: > I repeat: There are no new options! Please; that's unnecessary pedantry. Garrett is clearly referring to the new option argument for -H. To an ordinary user, that's an "option." The right answer, I believe, is that there's really no need to steer people hard away from cpio format. The existing man page for cpio recommends pax instead for large file support. That should be enough. -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
