cpio - differences between Solaris 1.x and 2.x ?
Tim Porter
I have recently upgraded our Sun SPARC system from SunOS 4.1.3 to Solaris
2.5.1. We used to use cpio with the options '-icdB' and '-ocmB'. The '-c'
option was supposed to write the headers in ASCII character format for
maximum portability.
I now notice (from the man page) that under Solaris 2.x the '-H odc'
option is recommended for maximum portability, and the '-c' option is only
for SVR4-based systems. Has the '-c' option changed, or has it always been
like this. If it is the same, then I see no harm in continuing to use it,
but if it's changed, I don't want my tapes to suddenly become incompatible
with other systems.
Can anyone tell me what's going on?
Thanks in advance,
Tim
-----------------------------------------------------------------------
Tim Porter | t.po...@fcrd.gov.uk
Forestry Commission, Research Division, | "All opinions expressed are my
UK | own, not those of my company"
-----------------------------------------------------------------------
Richard L. Hamilton
Tim Porter wrote:
>
> I have recently upgraded our Sun SPARC system from SunOS 4.1.3 to Solaris
> 2.5.1. We used to use cpio with the options '-icdB' and '-ocmB'. The '-c'
> option was supposed to write the headers in ASCII character format for
> maximum portability.
>
> I now notice (from the man page) that under Solaris 2.x the '-H odc'
> option is recommended for maximum portability, and the '-c' option is only
> for SVR4-based systems. Has the '-c' option changed, or has it always been
> like this. If it is the same, then I see no harm in continuing to use it,
> but if it's changed, I don't want my tapes to suddenly become incompatible
> with other systems.
>
> Can anyone tell me what's going on?
>
The -c option uses the natural size of uids, gids, device numbers
for the platform (which grew from 4.1.x to Solaris 2.x). The
-H odc option (available on Solaris 2.x only) uses the old SunOS
4.1.x sizes of these numbers in the headers for backwards compatibility.
However, you only need to use that when creating a cpio file on
Solaris 2.x that will be read on SunOS 4.1.x (see below for why you
can still use cpio -ic on Solaris 2.x to read a file produced by
cpio -oc on SunOS 4.1.x).
So you cannot take a file produced by cpio -oc on Solaris 2.x and
un-cpio it on SunOS 4.1.x. However, cpio -ic on Solaris 2.x is
smart enough to accept either either SunOS 4.1.x or Solaris 2.x
cpio -oc files (I tried). I don't know if that smart behavior of
cpio -ic on Solaris 2.x holds for all x, but I'm pretty sure it's
good for at least x >= 4.
--
ftp> get |fortune
377 I/O error: smart remark generator failed
mailto:rlh...@mindwarp.smart.net http://www.smart.net/~rlhamil
Paul Eggert
por...@fcrd.gov.uk (Tim Porter) writes:
> Can anyone tell me what's going on?
Yes: people are using `tar' instead of `cpio', by and large.
Not that `tar' is immune to porting problems either,
but in practice it tends to be more widely used and more reliable.
I stopped using cpio years ago, after it silently bungled archives
containing files whose inode numbers were greater than 65535, and I've
never regretted that decision. I'm sure that cpio bug has been fixed
since then, but the symptoms that you describe show that the problem
still exists in some form.
Joerg Schilling
In article <584j8q$895$1...@shade.twinsun.com>,
This has not been a cpio bug. But....
The cpio source has been from AT&T where the C-library supports
the %ho format to -> Mask to unsigned short and then output octal.
On BSD based C-libraries this printf format is not supported (h is ignored).
For this reason the cpio program on SunOS <= 4.x outputs 11 bytes instead
of 6 bytes and so produces even in -c mode a data stream that can never
read back :-)
Remember: cpio has at least 6 different formats that are totally incompatible
to each other.
Tar data streams will be much more compatible to different versions and
allow at least most of the files to be extracted on a different system.
Even though most tar implementations have implementation bugs, tar is
the data exchange format that has the best chance to be understood.
For a list of the bugs of the different tar implementations look at:
ftp://ftp.fokus.gmd.de/pub/unix/star/README.otherbugs
For a tar implementation that has no known bugs, will read all
(currently except HP-UX) tar streams and is the fastest implementation
at all (faster than ufsdump) look at:
ftp://ftp.fokus.gmd.de/pub/unix/star
for the rest of the goods.
Joerg
--
EMail: jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
j...@cs.tu-berlin.de (uni) If you don't have iso-8859-1
j...@fokus.gmd.de (work) chars my name is
URL: http://www.fokus.gmd.de/usr/schilling J"org Schilling
Christian Kuehnke
j...@cs.tu-berlin.de (Joerg Schilling) writes:
> For a tar implementation that has no known bugs, will read all
> (currently except HP-UX) tar streams and is the fastest implementation
> at all (faster than ufsdump) look at:
>
> ftp://ftp.fokus.gmd.de/pub/unix/star
>
> for the rest of the goods.
Nice. But why don't you provide the source?
--
Christia...@Informatik.Uni-Oldenburg.DE|Tel.: +49 441 592 652 (private)
|Tel.: +49 441 798 2978 (work)
Winter? Solaris keeps your CPU and Disk hot! |Fax : +49 441 798 2980 (work)
Joerg Schilling
In article <5892f4$2...@news.Informatik.Uni-Oldenburg.DE>,
Christian Kuehnke <Christia...@arbi.Informatik.Uni-Oldenburg.DE> wrote:
>
>j...@cs.tu-berlin.de (Joerg Schilling) writes:
>> For a tar implementation that has no known bugs, will read all
>> (currently except HP-UX) tar streams and is the fastest implementation
>> at all (faster than ufsdump) look at:
>>
>> ftp://ftp.fokus.gmd.de/pub/unix/star
>>
>> for the rest of the goods.
>
>Nice. But why don't you provide the source?
I always intended to provide star in source.
There are some reasons, why I din't do this up to now:
1) I dont want star to go the same way as gnu tar
You remember...
Gnu tar has been first written in August 1985 by John Gilmore,ihnp4!hoptoad!gnu.
It has been brought to the public at the Sun User Group meeting in december 1987
in San Jose as 'sugtar'. This version was really nice.
The actual version has been ported to death.
For this reason, I want to have star in my hands until I know the line for
portability to other systems is clear.
Star has been first written in 1982 by me. The main growth in functionality
did come in May 1985. Although star has been designed to be very portable,
id did run only on UNOS, SYSVr0-2, SunOS and Solaris. The major porting effort
has been taken in 1994. It now runs on
SunOS, Solaris, HP-UX, IRIX, Linux, DG/UX, AIX
2) Makefile system
In May 1996 I made a makefile sytstem that allows simultaneous compilation
on all supported platforms. This still needs some fine tuning until it may
do the way to the public.
I expect star to be available in souce in January 1997.
Joerg
P.S. Star has been ported to DG/UX with the help of Data General.
It will soon be available on Data General systems as a fast backup.
PP.S. GMD in Birlinghoven currently switches from 2MB/s X.25 to
34 MB/s ATM. For this reason our ftp server may not be reacheable
from outside germany until the mid of the next week.