From pinard@icule.progiciels-bpi.ca Sun May 17 23:50:27 1998
X-From-Line: VM Tue Jan  9 10:07:27 1996
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	["7784" "Mon" "8" "January" "1996" "23:34:07" "-0500" "pinard@icule.progiciels-bpi.ca" "pinard@icule.progiciels-bpi.ca" "<199601090434.XAA03657@icule.progiciels-bpi.ca>" "144" "Re: cpio for MSDOS" "^From:" nil nil "1" "1996010904:34:07" "cpio for MSDOS" (number " " mark "     " thread-indent "pinard@icule.prog Jan  8  144/7784  Re: cpio for MSDOS\n") "<199601090324.UAA11553@creche.cygnus.com>"]
	("automake"))
Received: by drip.colorado.edu (cu.generic.890828)
Received: from darkstar.cygnus.com (darkstar.cygnus.com [192.203.188.2]) by cygnus.com (8.6.12/8.6.9) with ESMTP id FAA14815 for <tromey@drip.colorado.edu>; Tue, 9 Jan 1996 05:18:10 -0800
Received: from iros1.IRO.UMontreal.CA (iros1.IRO.UMontreal.CA [132.204.32.21]) by darkstar.cygnus.com (8.6.12/8.6.9) with ESMTP id GAA11262 for <tromey@creche.cygnus.com>; Tue, 9 Jan 1996 06:18:03 -0700
Received: from icule.progiciels-bpi.ca (uucp@localhost) by iros1.IRO.UMontreal.CA (8.6.12/8.6.12) with UUCP id IAA20206 for tromey@creche.cygnus.com; Tue, 9 Jan 1996 08:17:56 -0500
Received: (from pinard@localhost) by icule.progiciels-bpi.ca (8.6.12/8.6.9) id XAA03657; Mon, 8 Jan 1996 23:34:07 -0500
Message-ID: <m1u3tblevk.fsf@totally-fudged-out-message-id>
Gnus-Warning: This is a duplicate of message <m1g24wryjf.fsf@totally-fudged-out-message-id>
Original-Message-ID: <m1g24wryjf.fsf@totally-fudged-out-message-id>
Gnus-Warning: This is a duplicate of message <199601090434.XAA03657@icule.progiciels-bpi.ca>
Original-Message-Id: <199601090434.XAA03657@icule.progiciels-bpi.ca>
In-Reply-To: <199601090324.UAA11553@creche.cygnus.com> (message from Tom
	Tromey on Mon, 8 Jan 1996 20:24:25 -0700)
Reply-To: pinard@iro.umontreal.ca
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
From: =?ISO-8859-1?Q?Fran=E7ois_Pinard?= <pinard@icule.progiciels-bpi.ca>
To: tromey@creche.cygnus.com
Subject: Re: cpio for MSDOS
Date: Mon, 8 Jan 1996 23:34:07 -0500
Xref: creche.cygnus.com mail.cpio:3
Lines: 145
X-Gnus-Newsgroup: mail.cpio:3   Sun Apr 13 23:56:35 1997

Hey, hey!  Playing with your brand new Linux machine? :-) You have
it directly connected to the net?  Are you tromey@cygnus.com, now?
What is your preferred email address?  Jim and you are moving all
the time...  Am I the only one around having some stability? :-)

   Actually, I am interested in MS-DOS portability.

So do I, for tar!  gzip and tar are necessary to get anything out
of prep, so I think we should make an exception to GNU disinterest
for MS-DOS and have them exceptionally portable, if easily doable.
gzip is all done.  tar is not completely yet.  I'm glad that we
share this concern too, in view of a later cpio/tar merge.

   Not sure how it is going to fit in with gettext though.  But that
   is for the porter to work out :-)

I may *ought* to have gettext on MS-DOS for a contract, soon.  But I
plan to limit myself to 80386 and higher systems, and depend on GO32
and DJGPP.  No Microsoft C, neither Borland's Turbo-C, or others...

   I'll probably contact all those people and try to get some sort
   of GNU(ish) cpio team together, assuming one of them is willing.

You might also be mildly interested in my administrative files for
msdos, around tar.  They should be reachable on the FSF machines
as ~pinard/tar/admins/msdos or else, on mere request.  Here are
the contents.  In fact, the RMAIL file is the important one, as it
indirectly contains a list of interested people, too.  Some of the
other code is not free, and might not free-able.  I'm interested in
an MS-DOS port, but in low priority.


0 pinard@icule:~/tar/admin/msdos) v -Ra
total 233
drwxr-xr-x   6 pinard   bin          1024 Jan  8 21:16 .
drwxr-xr-x   9 pinard   bin          1024 Dec 29 20:24 ..
-rw-r--r--   1 pinard   bin           272 Jan  7 20:06 Makefile.old
-rw-r--r--   1 pinard   bin        102704 Dec 31 19:31 RMAIL
-rw-r--r--   1 pinard   bin         21405 Jan  8 21:15 RMAIL-os2
-rw-r--r--   1 pinard   bin        103058 Dec 31 10:53 RMAIL~
drwxr-xr-x   2 pinard   bin          1024 Jan  5  1995 aspi-1.10
drwxr-xr-x   2 pinard   bin          1024 Feb 13  1995 dos-1.11.2
drwxr-xr-x   2 pinard   bin          1024 Jul  3  1995 gnu
drwxr-xr-x   2 pinard   bin          1024 Jan  4  1995 win-1.11.2

aspi-1.10:
total 193
drwxr-xr-x   2 pinard   bin          1024 Jan  5  1995 .
drwxr-xr-x   6 pinard   bin          1024 Jan  8 21:16 ..
-r--r--r--   1 pinard   bin          4890 Jan 14  1992 ASPI.DOC
-rw-r--r--   1 pinard   bin          2182 Jan  5  1995 Makefile.MSC
-rw-r--r--   1 pinard   bin          2739 Jan  5  1995 Makefile.diffs
-rw-r--r--   1 pinard   bin           308 Jan 14  1992 READ_ME_ASPI
-r--r--r--   1 pinard   bin         29714 Jan 14  1992 aspi.c
-rw-r--r--   1 pinard   bin          5119 Jan 14  1992 aspi.h
-r--r--r--   1 pinard   bin          6257 Jan 14  1992 ctctrl.c
-r--r--r--   1 pinard   bin         20403 Jan 14  1992 ctctrl.exe
-rw-r--r--   1 pinard   bin          2654 Jan  4  1995 diffarch.c.diffs
-rw-r--r--   1 pinard   bin           222 Jan 14  1992 linkcmd
-rw-r--r--   1 pinard   bin           294 Jan  4  1995 port.c.diffs
-rw-r--r--   1 pinard   bin          1142 Jan  4  1995 rmt.h.diffs
-rw-r--r--   1 pinard   bin          5198 Jan 14  1992 scsi.h
-rw-r--r--   1 pinard   bin          3015 Jan 14  1992 scsierr.h
-r--r--r--   1 pinard   bin        100147 Jan 14  1992 tar.exe

dos-1.11.2:
total 538
drwxr-xr-x   2 pinard   bin          1024 Feb 13  1995 .
drwxr-xr-x   6 pinard   bin          1024 Jan  8 21:16 ..
-rw-r--r--   1 pinard   bin           627 Jan  4  1995 INDEX
-rw-r--r--   1 pinard   bin          5352 Mar 18  1994 alloca.c
-rw-r--r--   1 pinard   bin         40600 Feb 22  1994 aspi.c
-rw-r--r--   1 pinard   bin          5125 Feb 22  1994 aspi.h
-rw-r--r--   1 pinard   bin           131 Apr  9  1994 bcccmds
-rw-r--r--   1 pinard   bin          2377 Jan  4  1995 buffer.c.diffs
-rw-r--r--   1 pinard   bin          1350 Jul 25  1994 changes.log
-rw-r--r--   1 pinard   bin          2151 Jan  4  1995 create.c.diffs
-rw-r--r--   1 pinard   bin          6537 Feb 22  1994 ctctrl.c
-rw-r--r--   1 pinard   bin         41568 Jul 25  1994 ctctrl.exe
-rw-r--r--   1 pinard   bin          3602 Jun 20  1994 devices.c
-rw-r--r--   1 pinard   bin          3275 Mar 13  1994 devices.h
-rw-r--r--   1 pinard   bin          2503 Jan  4  1995 diffarch.c.diffs
-rw-r--r--   1 pinard   bin         14287 May 23  1994 dosargs.c
-rw-r--r--   1 pinard   bin          4026 Jan  4  1995 extract.c.diffs
-rw-r--r--   1 pinard   bin         12978 Mar 22  1994 flopio.c
-rw-r--r--   1 pinard   bin         37137 Feb 22  1994 getdate.c
-rw-r--r--   1 pinard   bin         55699 Jan  4  1995 getdate.c.diffs
-rw-r--r--   1 pinard   bin           610 Feb 22  1994 getpages.h
-rw-r--r--   1 pinard   bin          1313 Jan  4  1995 gnu.c.diffs
-rw-r--r--   1 pinard   bin          3812 Jul 25  1994 makefile
-rw-r--r--   1 pinard   bin           950 Jan  4  1995 msd_dir.c.diffs
-rw-r--r--   1 pinard   bin          8092 Jun 21  1994 ntar.doc
-rw-r--r--   1 pinard   bin           557 Jan  4  1995 port.c.diffs
-rw-r--r--   1 pinard   bin           987 Jan  4  1995 port.h.diffs
-rw-r--r--   1 pinard   bin         30177 Jul  8  1992 readme.tcp
-rw-r--r--   1 pinard   bin          5890 Feb 22  1994 scsi.h
-rw-r--r--   1 pinard   bin          3060 Feb 22  1994 scsierr.h
-rw-r--r--   1 pinard   bin          6214 Jan  4  1995 tar.c.diffs
-rw-r--r--   1 pinard   bin        199104 Jul 25  1994 tar.exe
-rw-r--r--   1 pinard   bin          1851 Jan  4  1995 tar.h.diffs
-rw-r--r--   1 pinard   bin         13117 Jul 25  1994 tcp.c
-rw-r--r--   1 pinard   bin           210 Mar 31  1994 test.c
-rw-r--r--   1 pinard   bin            16 Jun 30  1994 testpad.h
-rw-r--r--   1 pinard   bin          1208 Jan  4  1995 update.c.diffs
-rw-r--r--   1 pinard   bin            90 Apr  9  1994 wattcp.cfg
-rw-r--r--   1 pinard   bin          3223 Jan  4  1995 wattcp.dif

gnu:
total 19
drwxr-xr-x   2 pinard   bin          1024 Jul  3  1995 .
drwxr-xr-x   6 pinard   bin          1024 Jan  8 21:16 ..
-rw-r--r--   1 pinard   bin          1795 Jun 23  1995 makefile.pc
-rw-r--r--   1 pinard   bin          1680 Jun 23  1995 makefile.pc.3
-rw-r--r--   1 pinard   bin          4502 May  2  1995 msd_dir.c
-rw-r--r--   1 pinard   bin          1060 Sep 18  1992 msd_dir.h
-rw-r--r--   1 pinard   bin          6079 Aug 22  1992 tcexparg.c

win-1.11.2:
total 281
drwxr-xr-x   2 pinard   bin          1024 Jan  4  1995 .
drwxr-xr-x   6 pinard   bin          1024 Jan  8 21:16 ..
-rw-r--r--   1 pinard   bin          1122 Jan  4  1995 buffer.c.diffs
-rw-r--r--   1 pinard   bin           320 Jan  4  1995 create.c.diffs
-rw-r--r--   1 pinard   bin          1011 Jan  4  1995 devices.c.diffs
-rw-r--r--   1 pinard   bin           840 Jan  4  1995 dosargs.c.diffs
-rw-r--r--   1 pinard   bin           344 Jan  4  1995 list.c.diffs
-rw-r--r--   1 pinard   bin          1720 Sep 19  1994 readme.1st
-rw-r--r--   1 pinard   bin          6405 Jan  4  1995 tar.c.diffs
-rw-r--r--   1 pinard   bin           417 Jan  4  1995 tar.h.diffs
-rw-r--r--   1 pinard   bin           331 Jan  4  1995 update.c.diffs
-rw-r--r--   1 pinard   bin         28609 Aug  8  1994 winsock.h
-rw-r--r--   1 pinard   bin         40671 Sep 23  1994 wtar.c
-rw-r--r--   1 pinard   bin           296 Sep 20  1994 wtar.def
-rw-r--r--   1 pinard   bin          4556 Oct 20  1994 wtar.doc
-rw-r--r--   1 pinard   bin        182874 Dec  8  1994 wtar.exe
-rw-r--r--   1 pinard   bin           766 Sep 14  1994 wtar.ico
-rw-r--r--   1 pinard   bin           362 Sep 15  1994 wtar.ini
-rw-r--r--   1 pinard   bin          3697 Sep 14  1994 wtar.rc


-- 
Frangois Pinard        ``Happy GNU Year!''       pinard@iro.umontreal.ca
A New Year's gift?  Give us Programming Freedom!  Write lpf@uunet.uu.net



From johno@paul.rutgers.edu Sun May 17 23:50:31 1998
X-From-Line: VM Tue Jun  4 16:15:57 1996
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	["2478" "Tue" "4" "June" "1996" "18:00:48" "-0400" "John Oleynick" "johno@paul.rutgers.edu" "<199606042200.SAA00581@john.rutgers.edu>" "71" "cpio bug?" "^From:" nil nil "6" "1996060422:00:48" "cpio bug?" (number " " mark "     " thread-indent "John Oleynick     Jun  4   71/2478  cpio bug?\n") nil]
	nil)
Received: by drip.colorado.edu (cu.generic.890828)
Received: from cygnus.com (cygnus.com [140.174.1.1]) by boulder.Colorado.EDU (8.6.13/8.6.12/UnixOps) with ESMTP id QAA25037 for <tromey@drip.colorado.edu>; Tue, 4 Jun 1996 16:01:43 -0600
Received: from john.rutgers.edu (johno@john.rutgers.edu [128.6.5.54]) by cygnus.com (8.6.12/8.6.9) with ESMTP id PAA08132 for <tromey@cygnus.com>; Tue, 4 Jun 1996 15:00:19 -0700
Received: from localhost (johno@localhost) by john.rutgers.edu (8.6.12+bestmx+oldruq+newsunq/8.6.12) with ESMTP id SAA00581; Tue, 4 Jun 1996 18:00:49 -0400
Message-ID: <m13f0vlevj.fsf@totally-fudged-out-message-id>
Gnus-Warning: This is a duplicate of message <m1afv4qjyy.fsf@totally-fudged-out-message-id>
Original-Message-ID: <m1afv4qjyy.fsf@totally-fudged-out-message-id>
Gnus-Warning: This is a duplicate of message <199606042200.SAA00581@john.rutgers.edu>
Original-Message-Id: <199606042200.SAA00581@john.rutgers.edu>
From: John Oleynick <johno@paul.rutgers.edu>
To: tromey@cygnus.com
Cc: farzin@blitz.de
Subject: cpio bug?
Date: Tue, 04 Jun 1996 18:00:48 -0400
Xref: creche.cygnus.com mail.cpio:4
Lines: 72
X-Gnus-Newsgroup: mail.cpio:4   Sun Apr 13 23:56:38 1997

Hi Tom,
     Someone (Farzin Atefi <farzin@blitz.de) sent me email about a
problem with cpio and I think they've found a real bug in it.  I don't
have time to figure out and test a real fix but I can tell you where I
think the problem is.  Their problem was using multi-volume tapes.
When they backup their system it seems to work fine writing multiple
tapes, but if they try to restore cpio reads the first tape and then
gets an i/o error (or something like that; I don't have the original
message handy).  I think the problem is in util.c.  In
tape_empty_output_buffer () there's alot of code to handle end of tape
when writing an archive:

  bytes_written = rmtwrite (out_des, output_buffer, output_size);
  if (bytes_written != output_size)
    {
      int rest_bytes_written;
      int rest_output_size;

      if (output_is_special
          && (bytes_written >= 0
              || (bytes_written < 0
                  && (errno == ENOSPC || errno == EIO || errno == ENXIO))))
        {
          get_next_reel (out_des);
          if (bytes_written > 0)
            rest_output_size = output_size - bytes_written;
          else
            rest_output_size = output_size;
          rest_bytes_written = rmtwrite (out_des, output_buffer,
                                         rest_output_size);
          if (rest_bytes_written != rest_output_size)
            error (1, errno, "write error");
        }
      else
        error (1, errno, "write error");
    }
  output_bytes += output_size;
  out_buff = output_buffer;
  output_size = 0;


But when reading tapes, tape_fill_input_buffer () doesn't handle end of
tape as carefully:

  num_bytes = (num_bytes < io_block_size) ? num_bytes : io_block_size;
  input_size = rmtread (in_des, input_buffer, num_bytes);
  if (input_size == 0 && input_is_special)
    {
      get_next_reel (in_des);
      input_size = rmtread (in_des, input_buffer, num_bytes);
    }
  if (input_size < 0)
    error (1, errno, "read error");
  if (input_size == 0)
    {
      error (0, 0, "premature end of file");
      exit (1);
    }
  input_bytes += input_size;

I think the problem that Farzin has run into is that it looks like the
Linux tape driver returns -1 and EIO if you try to read and hit end of
tape.  Now that I think about it some more, I wonder if that in
itself is the bug.  Should the tape driver return -1 or should it return
0 at the end of tape?  Maybe the bug is really the Linux tape driver,
and not cpio?

		John





From farzin@atefi.blitz.de Sun May 17 23:50:31 1998
X-From-Line: VM Sun Jun  9 22:19:58 1996
Status: RO
X-VM-v5-Data: ([nil nil nil nil t nil nil nil nil]
	["939" "Sun" "9" "June" "1996" "20:50:41" "+0200" "Farzin Atefi" "farzin@atefi.blitz.de" "<199606091850.UAA29277@atefi.blitz.de>" "26" "Re: cpio bug?" "^From:" nil nil "6" "1996060918:50:41" "cpio bug?" (number " " mark "  R  " thread-indent "Farzin Atefi      Jun  9   26/939   Re: cpio bug?\n") "<199606042200.SAA00581@john.rutgers.edu>"]
	nil)
Received: by drip.colorado.edu (cu.generic.890828)
Received: from cumulus.blitz.de (uucp@cumulus.blitz.de [194.113.47.19]) by cygnus.com (8.6.12/8.6.9) with ESMTP id LAA05938 for <tromey@cygnus.com>; Sun, 9 Jun 1996 11:56:08 -0700
Received: (from uucp@localhost) by cumulus.blitz.de (8.6.12/8.6.11) with UUCP id UAA20714; Sun, 9 Jun 1996 20:56:07 +0200
Received: (from farzin@localhost) by atefi.blitz.de (8.6.12/8.6.9) id UAA29277; Sun, 9 Jun 1996 20:50:42 +0200
Message-ID: <m120gflevj.fsf@totally-fudged-out-message-id>
Gnus-Warning: This is a duplicate of message <m17mq8qjyy.fsf@totally-fudged-out-message-id>
Original-Message-ID: <m17mq8qjyy.fsf@totally-fudged-out-message-id>
Gnus-Warning: This is a duplicate of message <199606091850.UAA29277@atefi.blitz.de>
Original-Message-Id: <199606091850.UAA29277@atefi.blitz.de>
In-Reply-To: <199606042200.SAA00581@john.rutgers.edu> from "John Oleynick" at Jun 4, 96 06:00:48 pm
X-Mailer: ELM [version 2.4 PL24]
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Content-Length: 938       
From: Farzin Atefi <farzin@atefi.blitz.de>
To: johno@paul.rutgers.edu (John Oleynick)
Cc: tromey@cygnus.com
Subject: Re: cpio bug?
Date: Sun, 9 Jun 1996 20:50:41 +0200 (MET DST)
Xref: creche.cygnus.com mail.cpio:5
Lines: 27
X-Gnus-Newsgroup: mail.cpio:5   Sun Apr 13 23:56:39 1997

John Oleynick wrote:
> 
> Hi Tom,
>      Someone (Farzin Atefi <farzin@blitz.de) sent me email about a
> problem with cpio and I think they've found a real bug in it.  I don't
[...]
> I think the problem that Farzin has run into is that it looks like the
> Linux tape driver returns -1 and EIO if you try to read and hit end of
> tape.  Now that I think about it some more, I wonder if that in
> itself is the bug.  Should the tape driver return -1 or should it return
> 0 at the end of tape?  Maybe the bug is really the Linux tape driver,
> and not cpio?
> 
Hi John, hi Tom,
I've been away for a week, that's why I didn't answer sooner.
To sum up my experiences again, the error occurs both when reading
with and without -B, also when the tape ist written without -B.
Tar seems to work correctly, so I suggest having a glance at it's
source.

Looking forward to hearing from you,
Farzin

-- 
For more information finger farzin@blitz.de



From farzin@atefi.blitz.de Sun May 17 23:50:31 1998
X-From-Line: VM Mon Jun 10 09:17:36 1996
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	["1412" "Mon" "10" "June" "1996" "14:31:45" "+0200" "Farzin Atefi" "farzin@atefi.blitz.de" "<199606101231.OAA06782@atefi.blitz.de>" "47" "Re: cpio bug?" "^From:" nil nil "6" "1996061012:31:45" "cpio bug?" (number " " mark "     " thread-indent "Farzin Atefi      Jun 10   47/1412  Re: cpio bug?\n") "<199606100530.XAA01062@creche.cygnus.com>"]
	nil)
Received: by drip.colorado.edu (cu.generic.890828)
Received: from cumulus.blitz.de (uucp@cumulus.blitz.de [194.113.47.19]) by cygnus.com (8.6.12/8.6.9) with ESMTP id FAA02734 for <tromey@cygnus.com>; Mon, 10 Jun 1996 05:51:30 -0700
Received: (from uucp@localhost) by cumulus.blitz.de (8.6.12/8.6.11) with UUCP id OAA00798; Mon, 10 Jun 1996 14:51:51 +0200
Received: (from farzin@localhost) by atefi.blitz.de (8.6.12/8.6.9) id OAA06782; Mon, 10 Jun 1996 14:31:46 +0200
Message-ID: <m1zq33k0b3.fsf@totally-fudged-out-message-id>
Gnus-Warning: This is a duplicate of message <m1685sqjyy.fsf@totally-fudged-out-message-id>
Original-Message-ID: <m1685sqjyy.fsf@totally-fudged-out-message-id>
Gnus-Warning: This is a duplicate of message <199606101231.OAA06782@atefi.blitz.de>
Original-Message-Id: <199606101231.OAA06782@atefi.blitz.de>
In-Reply-To: <199606100530.XAA01062@creche.cygnus.com> from "Tom Tromey" at Jun 9, 96 11:30:01 pm
X-Mailer: ELM [version 2.4 PL24]
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Content-Length: 1411      
From: Farzin Atefi <farzin@atefi.blitz.de>
To: tromey@cygnus.com
Cc: farzin@atefi.blitz.de, johno@paul.rutgers.edu
Subject: Re: cpio bug?
Date: Mon, 10 Jun 1996 14:31:45 +0200 (MET DST)
Xref: creche.cygnus.com mail.cpio:6
Lines: 48
X-Gnus-Newsgroup: mail.cpio:6   Sun Apr 13 23:56:41 1997

Tom Tromey wrote:
> 
> Farzin> Hi John, hi Tom, I've been away for a week, that's why I
> Farzin> didn't answer sooner.
> 
> I'm just a flake... I'll take a look at this problem as soon as I can,
> which probably means in about a week.  I'm pretty busy with real work
> right now, unfortunately.

Hi,
I had another look at the code myself and found the culprit:
*** util.c	Mon Jun 10 11:24:52 1996
--- util.c.orig	Mon Jun 10 11:24:27 1996
***************
*** 868,874 ****
      error (2, errno, CONSOLE);
  
    old_tape_des = tape_des;
! /*  tape_offline (tape_des); */
    rmtclose (tape_des);
  
    /* Give message and wait for carrage return.  User should hit carrage return
--- 868,874 ----
      error (2, errno, CONSOLE);
  
    old_tape_des = tape_des;
!   tape_offline (tape_des);
    rmtclose (tape_des);
  
    /* Give message and wait for carrage return.  User should hit carrage return

I don't know what tape_offline is supposed to do, so I just
commented it out. Now everything seems to be OK. I'm almost
certain that the problem occured due to a missing EOF mark
at the and of the tape. dd and mt also work properly when
the tape is written with the patched cpio.

At the moment, I'm happy with this. When you find some time,
please try to see what tape_offline is about.
BTW, the otherwise very similar tar code just closes the
device.

Farzin

-- 
For more information finger farzin@blitz.de



From branderh@debian.IAEhv.nl Sun May 17 23:50:31 1998
X-From-Line: VM Tue Sep  3 16:33:29 1996
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	["466" "Thu" "29" "August" "1996" "16:43:08" "+0200" "branderh@debian.iaehv.nl" "branderh@debian.iaehv.nl" "<m0uw8JP-0002gEC@debian.iaehv.nl>" "13" "cpio .. pot" "^From:" nil nil "8" "1996082914:43:08" "cpio .. pot" (number " " mark "     " thread-indent "branderh@debian.i Aug 29   13/466   cpio .. pot\n") nil]
	nil)
Received: by drip.colorado.edu (cu.generic.890828)
Received: from iaehv.IAEhv.nl (root@iaehv.IAEhv.nl [194.151.64.2]) by cygnus.com (8.6.12/8.6.9) with ESMTP id FAA05156 for <tromey@cygnus.com>; Thu, 29 Aug 1996 05:33:54 -0700
Received: from debian.iaehv.nl (pm5d12.IAEhv.nl [194.151.70.141]) 
          by iaehv.IAEhv.nl (8.6.13/1.63) with SMTP; pid 5387
          on Thu, 29 Aug 1996 14:33:34 +0200; id OAA05387
          efrom: branderh@debian.IAEhv.nl; eto: <tromey@cygnus.com> 
Received: by debian.iaehv.nl
	id m0uw8JP-0002gEC
	(Debian /\oo/\ Smail3.1.29.1 #29.37); Thu, 29 Aug 96 16:43 MET DST
Message-ID: <m1hgpbilqm.fsf@totally-fudged-out-message-id>
Gnus-Warning: This is a duplicate of message <m17mq8kxp3.fsf@totally-fudged-out-message-id>
Original-Message-ID: <m17mq8kxp3.fsf@totally-fudged-out-message-id>
Gnus-Warning: This is a duplicate of message <m0uw8JP-0002gEC@debian.iaehv.nl>
Original-Message-Id: <m0uw8JP-0002gEC@debian.iaehv.nl>
X-Mailer: ELM [version 2.4 PL25 PGP2]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Content-Length: 465       
From: branderh@debian.IAEhv.nl
To: tromey@cygnus.com
Subject: cpio .. pot
Date: Thu, 29 Aug 1996 16:43:08 +0200 (MET DST)
Xref: creche.cygnus.com mail.cpio:7
Lines: 14
X-Gnus-Newsgroup: mail.cpio:7   Sun Apr 13 23:56:44 1997

Hi,

I have seen on alpha.gnu.ai.mit.edu that you maintain the cpio
package.  I'm busy translating the messages into the dutch languages
but it seems that some messages from the cpio sources exceed the 79
or 80 characters.  This isn't how it should be and I ask you if you
would reformat the messages so that they fit on a 80 character wide
screen, translation and checking will be possible then.

Thanks for the maintanance,

Erick (Dutch translation coordinator)



From pinard@progiciels-bpi.ca Sun May 17 23:50:32 1998
X-From-Line: VM Thu Jul 18 12:12:48 1996
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	["552" "" "1" "" "1996" "13:13:50" "" "pinard@progiciels-bpi.ca" "pinard@progiciels-bpi.ca" "<199607181713.NAA03767@icule.progiciels-bpi.ca>" "15" "Re: [sanvila@unex.es: (tar pretest) Corrected patch (sorry!)]" "^From:" nil nil "" "2000000000:00:00" "[sanvila@unex.es: (tar pretest) Corrected patch (sorry!)]" (number " " mark "     " thread-indent "pinard@progiciels      1   15/552   Re: [sanvila@unex.es: (tar pretest) Corrected patch (sorry!)]\n") "<9607181000.AA13927@gnuisance.cern.ch.cern.ch>"]
	nil)
Received: by drip.colorado.edu (cu.generic.890828)
Received: from rtsq.grics.qc.ca (root@rtsq.grics.qc.ca [199.84.132.10]) by cygnus.com (8.6.12/8.6.9) with ESMTP id KAA01574 for <tromey@cygnus.com>; Thu, 18 Jul 1996 10:23:26 -0700
Received: by rtsq.grics.qc.ca (8.7.5/8.7.3) with UUCP id NAA09585 for tromey@cygnus.com; Thu, 18 Jul 1996 13:20:56 -0400
X-Authentication-Warning: rtsq.grics.qc.ca: uicule set sender to pinard@icule.progiciels-bpi.ca using -f
Received: by icule.progiciels-bpi.ca (8.7.5/8.7.3) id NAA03767; 1996-07-18 13:13:50-04:00
Message-ID: <m1afv3h765.fsf@totally-fudged-out-message-id>
Gnus-Warning: This is a duplicate of message <m1ybionqu1.fsf@totally-fudged-out-message-id>
Original-Message-ID: <m1ybionqu1.fsf@totally-fudged-out-message-id>
Gnus-Warning: This is a duplicate of message <199607181713.NAA03767@icule.progiciels-bpi.ca>
Original-Message-Id: <199607181713.NAA03767@icule.progiciels-bpi.ca>
In-Reply-To: <9607181000.AA13927@gnuisance.cern.ch.cern.ch>
	(Philippe.Defert@cern.ch)
Reply-To: pinard@iro.umontreal.ca
X-Face: "b_m|CE6#'Q8fliQrwHl9K,]PA_o'*S~Dva{~b1n*)K*A(BIwQW.:LY?t4~xhYka_.LV?Qq
 `}X|71X0ea&H]9Dsk!`kxBXlG;q$mLfv_vtaHK_rHFKu]4'<*LWCyUe@ZcI6"*wB5M@[m<Ok5/cC^=
 CxDhg=TJi^o[E
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
From: =?ISO-8859-1?Q?Fran=E7ois_Pinard?= <pinard@progiciels-bpi.ca>
To: Tom Tromey <tromey@cygnus.com>
Subject: Re: [sanvila@unex.es: (tar pretest) Corrected patch (sorry!)]
Date: 1996-07-18 13:13:50-04:00
Xref: creche.cygnus.com mail.cpio:8
Lines: 16
X-Gnus-Newsgroup: mail.cpio:8   Sun Apr 13 23:56:47 1997

Hi, Tom.  A tar pretester writes:

   - "rmt" is in conflict with cpio, which causes problem for us as we
   automate everything and the installation of tar is refused because
   there is a file name conflict.

Maybe, the same tar does not distribute mt, cpio should not distribute
rmt.  The real solution is, and we know it, a merge of the two packages.
For one of these long boring days :-).

--=20
Fran=E7ois Pinard         ``Vivement GNU!''        pinard@iro.umontreal.c=
a
Support Programming Freedom, join our League!  Ask lpf@lpf.org for info!



From pinard@IRO.UMontreal.CA Sun May 17 23:50:32 1998
X-From-Line: VM Thu Aug  8 09:19:06 1996
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil nil nil nil nil nil nil nil nil "<vr20hivuk9.fsf@raptor.IRO.UMontreal.CA>" nil "Re: Backup of Hurd systems" "^From:" nil nil nil "1996080814:07:02" "Backup of Hurd systems" nil "<199608071939.PAA03891@churchy.gnu.ai.mit.edu>"]
	nil)
Received: by drip.colorado.edu (cu.generic.890828)
Received: from castor.IRO.UMontreal.CA (castor.IRO.UMontreal.CA [132.204.32.22]) by cygnus.com (8.6.12/8.6.9) with ESMTP id HAA24693; Thu, 8 Aug 1996 07:08:01 -0700
Received: (from daemon@localhost) by castor.IRO.UMontreal.CA (8.7.5/8.7.3) id KAA03482 for tar-forum-outgoing; Thu, 8 Aug 1996 10:07:09 -0400 (EDT)
Received: from raptor.IRO.UMontreal.CA (raptor.IRO.UMontreal.CA [132.204.38.50]) by castor.IRO.UMontreal.CA (8.7.5/8.7.3) with ESMTP id KAA03476 for <ltar-forum@castor.IRO.UMontreal.CA>; Thu, 8 Aug 1996 10:07:04 -0400 (EDT)
Received: (from pinard@localhost) by raptor.IRO.UMontreal.CA (8.7.5/8.7.3) id KAA27950; Thu, 8 Aug 1996 10:07:03 -0400 (EDT)
References: <199608071939.PAA03891@churchy.gnu.ai.mit.edu>
X-Face: "b_m|CE6#'Q8fliQrwHl9K,]PA_o'*S~Dva{~b1n*)K*A(BIwQW.:LY?t4~xhYka_.LV?Qq
 `}X|71X0ea&H]9Dsk!`kxBXlG;q$mLfv_vtaHK_rHFKu]4'<*LWCyUe@ZcI6"*wB5M@[m<Ok5/cC^=
 CxDhg=TJi^o[E
In-Reply-To: thomas@gnu.ai.mit.edu's message of 1996-08-07 15:39:41-04:00
Message-ID: <m17mq7h764.fsf@totally-fudged-out-message-id>
Gnus-Warning: This is a duplicate of message <m1685snqu0.fsf@totally-fudged-out-message-id>
Original-Message-ID: <m1685snqu0.fsf@totally-fudged-out-message-id>
Gnus-Warning: This is a duplicate of message <vr20hivuk9.fsf@raptor.IRO.UMontreal.CA>
Original-Message-Id: <vr20hivuk9.fsf@raptor.IRO.UMontreal.CA>
X-Mailer: Red Gnus v0.6/Emacs 19.31
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Precedence: bulk
Reply-To: tar-forum@IRO.UMontreal.CA
From: =?ISO-8859-1?Q?Fran=E7ois_Pinard?= <pinard@IRO.UMontreal.CA>
Sender: owner-tar-forum@IRO.UMontreal.CA
To: thomas@gnu.ai.mit.edu (Thomas Bushnell)
Cc: n/BSG@IRO.UMontreal.CA, juo@klinzhai.rutgers.edu,
        tromey@cambric.colorado.edu, tar-forum@IRO.UMontreal.CA
Subject: Re: Backup of Hurd systems
Date: 08 Aug 1996 10:07:02 -0400
Xref: creche.cygnus.com mail.cpio:9
Lines: 29
X-Gnus-Newsgroup: mail.cpio:9   Sun Apr 13 23:56:49 1997

thomas@gnu.ai.mit.edu (Thomas Bushnell, n/BSG) writes:

   The Hurd has several filesystem characteristics in addition to those
   of Unix which GNU tar should be able to back up.  [...]
   Can we make definite plans to have suitable extensions made to GNU tar
   to support these extensions?

I'm definitely game for a tar supporting the Hurd.  However, there are
a few things moving in GNU tar, and careful planning is needed, indeed.
I would like tar to evolve more unified, and avoid letting him become a
mere heap of patches :-).
   
   I've CC-d the cpio maintainers because they might also want to support
   them, though it's less critical.

Tom Tromey and I share dreams about merging cpio and tar distributions,
and even sharing maintenance to a certain extent.  One logical step on the
way is having a convergence in the archive formats, or at least, in their
`.h' descriptions.  The `tar.h' file in tar 1.11.11 contains unfinished
descriptions (I know which is which), and should not be blindly used as
a starting point.

OK!  Let's say that the project of a Hurd supporting tar is launched!

-- 
Frangois Pinard         ``Vivement GNU!''        pinard@iro.umontreal.ca
Support Programming Freedom, join our League!  Ask lpf@lpf.org for info!



From thomas@gnu.ai.mit.edu Sun May 17 23:50:33 1998
X-From-Line: VM Wed Aug  7 13:57:07 1996
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	["470" "Wed" "7" "August" "1996" "15:39:41" "-0400" "Thomas Bushnell" "thomas@gnu.ai.mit.edu" "<199608071939.PAA03891@churchy.gnu.ai.mit.edu>" "18" "Backup of Hurd systems" "^From:" nil nil "8" "1996080719:39:41" "Backup of Hurd systems" (number " " mark "     " thread-indent "Thomas Bushnell   Aug  7   18/470   Backup of Hurd systems\n") nil]
	nil)
Received: by drip.colorado.edu (cu.generic.890828)
Received: by churchy.gnu.ai.mit.edu (8.6.12/8.6.12GNU) id PAA03891; Wed, 7 Aug 1996 15:39:41 -0400
Message-ID: <m1685rh764.fsf@totally-fudged-out-message-id>
Gnus-Warning: This is a duplicate of message <m17mq8nqu0.fsf@totally-fudged-out-message-id>
Original-Message-ID: <m17mq8nqu0.fsf@totally-fudged-out-message-id>
Gnus-Warning: This is a duplicate of message <199608071939.PAA03891@churchy.gnu.ai.mit.edu>
Original-Message-Id: <199608071939.PAA03891@churchy.gnu.ai.mit.edu>
X-Name-Change: My name used to be `Michael'; now it is `Thomas'.
X-Windows: Garbage at your fingertips.
From: thomas@gnu.ai.mit.edu (Thomas Bushnell, n/BSG)
To: pinard@iro.umontreal.ca
Cc: juo@klinzhai.rutgers.edu, tromey@cambric.colorado.edu
Subject: Backup of Hurd systems
Date: Wed, 7 Aug 1996 15:39:41 -0400
Xref: creche.cygnus.com mail.cpio:10
Lines: 19
X-Gnus-Newsgroup: mail.cpio:10   Sun Apr 13 23:57:03 1997


The Hurd has several filesystem characteristics in addition to those
of Unix which GNU tar should be able to back up.

These are:

o 32 bit modes, uids, and gids.
o A new uid-like beast called `author'.
o A `translator' which is a command line string.

Can we make definite plans to have suitable extensions made to GNU tar
to support these extensions?  

I've CC-d the cpio maintainers because they might also want to support
them, though it's less critical.

Thomas



From rfg@monkeys.com Sun May 17 23:50:33 1998
X-From-Line: nobody Wed Sep 11 14:28:20 1996
Received: by drip.colorado.edu (cu.generic.890828)
Received: from eagle.ns.net (root@eagle.ns.net [204.75.146.20]) by cygnus.com (8.6.12/8.6.9) with ESMTP id NAA17935 for <tromey@cygnus.com>; Wed, 11 Sep 1996 13:17:59 -0700
Received: from segfault.monkeys.com (segfault.monkeys.com [204.119.242.200]) by eagle.ns.net (8.6.13/8.6.10) with ESMTP id NAA25647; Wed, 11 Sep 1996 13:17:46 -0700
Received: from segfault.monkeys.com (rfg@localhost) by segfault.monkeys.com (8.7.3/8.7.3) with ESMTP id NAA10354; Wed, 11 Sep 1996 13:15:46 -0700 (PDT)
To: tromey@cygnus.com
Cc: John Oleynick <johno@paul.rutgers.edu>
Subject: Re: GNU cpio... bug or feature? 
In-Reply-To: Your message of 11 Sep 1996 13:16:22 -0600.
             <m1afuwkgl5.fsf@creche.cygnus.com> 
X-Copyright: (c) 1996 Ronald F. Guilmette; All rights reserved.
Date: Wed, 11 Sep 1996 13:15:45 -0700
Message-Id: <10353.842472945@segfault.monkeys.com>
From: "Ronald F. Guilmette" <rfg@monkeys.com>
Xref: creche.cygnus.com mail.cpio:11
Lines: 39
X-Gnus-Newsgroup: mail.cpio:11   Sun Apr 13 23:57:17 1997


In message <m1afuwkgl5.fsf@creche.cygnus.com>, you wrote:

>You might consider sending in your LynxOS changes for inclusion in a
>future version.  I assume they are mostly to the configuration code?

John Oleynick <johno@paul.rutgers.edu> suggested that also.

I am now trying to get ready to send you my patches... but there is a small
catch.

The most recently release version of LynxOS is 2.4.

On LynxOS 2.4 (and earlier) _none_ of the system libraries contain an
`rexec' function.  An `rexec' function is needed to completely build
GNU cpio (and also GNU tar, BTW).

I worde around this problem by stealing a copy of the BSD `rexec' library
function, hacking it until it compiled OK, and including it into the `src'
directory of cpio (making relevant changes in Makefile.in, etc, to accomodate
this change).

Now my assumption is that you can't and won't accept non-copylefted code
for inclusion into GNU cpio releases, so I'm now forced to backup and
see if there is a uable `rexec' function in GNU libc.  I am doing that
now.  If there is one, then I will substitute it and then send you a
complete set of patches.  If not however, I'm not sure what I will do.
I don't think that it would be terribly useful for either you or me to
spend time getting GNU cpio to the point where it will only _almost_
build on LynxOS.

P.S.  I have urged Lynx Real-Time Systems, Inc. to put an `rexec' into
their libraries for their next (2.5) release.  We will have to wait and
see how much effect this urging actually had.

-- Ron Guilmette, Roseville, CA -------- Infinite Monkeys & Co. ------------
---- E-mail: rfg@monkeys.com ----------- Purveyors of Compiler Test Suites -
------ Copyright (c) 1996 by Ronald F. Guilmette; All rights reserved. -----


From rfg@monkeys.com Sun May 17 23:50:34 1998
X-From-Line: nobody Wed Sep 11 14:52:22 1996
Received: by drip.colorado.edu (cu.generic.890828)
Received: from eagle.ns.net (root@eagle.ns.net [204.75.146.20]) by cygnus.com (8.6.12/8.6.9) with ESMTP id NAA19364 for <tromey@cygnus.com>; Wed, 11 Sep 1996 13:47:53 -0700
Received: from segfault.monkeys.com (segfault.monkeys.com [204.119.242.200]) by eagle.ns.net (8.6.13/8.6.10) with ESMTP id NAA26572; Wed, 11 Sep 1996 13:47:46 -0700
Received: from segfault.monkeys.com (rfg@localhost) by segfault.monkeys.com (8.7.3/8.7.3) with ESMTP id NAA10437; Wed, 11 Sep 1996 13:46:17 -0700 (PDT)
To: tromey@cygnus.com
Cc: John Oleynick <johno@paul.rutgers.edu>
Subject: Re: GNU cpio... bug or feature? 
Date: Wed, 11 Sep 1996 13:46:17 -0700
Message-Id: <10436.842474777@segfault.monkeys.com>
From: "Ronald F. Guilmette" <rfg@monkeys.com>
Xref: creche.cygnus.com mail.cpio:12
Lines: 19
X-Gnus-Newsgroup: mail.cpio:12   Sun Apr 13 23:57:20 1997


Hummm.... I was worried that if I sent you the cpio 2.4.2 patches that I
have for LynxOS, you would reject them because they include the (non-
copylefted) BSD `rexec' function.

So I fetched a fresh copy of glibc from prep and looked in it for an
pure GNU `rexec' function that I could use instead.

Guess what I found!  The `rexec' function in glibc is also the BSD one!

So I guess that I'll just send you the patches as I have them now.  I must
assume that if it is OK for the (non-copylefted) BSD rexec function to
be shipped out with GNU glibc, then it must also be OK if it gets included
also with GNU cpio.

-- Ron Guilmette, Roseville, CA -------- Infinite Monkeys & Co. ------------
---- E-mail: rfg@monkeys.com ----------- Purveyors of Compiler Test Suites -
------ Copyright (c) 1996 by Ronald F. Guilmette; All rights reserved. -----


From rfg@monkeys.com Sun May 17 23:50:35 1998
X-From-Line: nobody Wed Sep 11 15:06:46 1996
Received: by drip.colorado.edu (cu.generic.890828)
Received: from eagle.ns.net (root@eagle.ns.net [204.75.146.20]) by cygnus.com (8.6.12/8.6.9) with ESMTP id OAA20170 for <tromey@cygnus.com>; Wed, 11 Sep 1996 14:01:33 -0700
Received: from segfault.monkeys.com (segfault.monkeys.com [204.119.242.200]) by eagle.ns.net (8.6.13/8.6.10) with ESMTP id OAA27016; Wed, 11 Sep 1996 14:01:17 -0700
Received: from segfault.monkeys.com (rfg@localhost) by segfault.monkeys.com (8.7.3/8.7.3) with ESMTP id OAA10516; Wed, 11 Sep 1996 14:00:39 -0700 (PDT)
To: tromey@cygnus.com
Cc: bug-gnu-utils@prep.ai.mit.edu
Subject: GNU cpio 2.4.2 ported to LynxOS 2.4.0 (patches included)
Date: Wed, 11 Sep 1996 14:00:39 -0700
Message-Id: <10515.842475639@segfault.monkeys.com>
From: "Ronald F. Guilmette" <rfg@monkeys.com>
Xref: creche.cygnus.com mail.cpio:13
Lines: 1265
X-Gnus-Newsgroup: mail.cpio:13   Sun Apr 13 23:57:22 1997


Here are the patches I have used to make GNU cpio 2.4.2 work on LynxOS 2.4.0.
I include also a set of relevant ChangeLog entries.

Wed Sep 11 13:50:50 PDT 1996  Ron Guilmette  (rfg@monkeys.com)

	* Ported 2.4.2 to LynxOS 2.4.0:
	* Makefile.in: Include rexec.o and ruserpass.o in OBJS.  (No library
	  on LynxOS 2.4.0 supplies these needed functons.)
	* Makefile.in:  Put `-' in front of all `rm' commands (as per GNU
	  standards).
	* configure.in: Added `rexec' and `ruserpass' in call to AC_CHECK_FUNCS.
	  (Some OSes, e.g. LynxOS, don't have these in any library.)
	* configure.in:  Call to AC_CHECK_LIB to check for `getservbyname'
	  in libbsd.a (on LynxOS).
	* rexec.c:  New file.  Slightly hacked BSD version (for LynxOS only).
	* ruserpass.c:  ditto


diff -rc2pP src/cpio-2.4.2/Makefile.in powerpc-lynxos-2.4/cpio-2.4.2/Makefile.in
*** src/cpio-2.4.2/Makefile.in	Wed Dec 20 08:28:30 1995
--- powerpc-lynxos-2.4/cpio-2.4.2/Makefile.in	Fri Aug 23 10:14:55 1996
*************** userspec.c xstrdup.c bcopy.c fnmatch.c m
*** 105,114 ****
  OBJS = copyin.o copyout.o copypass.o defer.o dstring.o global.o \
  main.o tar.o util.o error.o getopt.o getopt1.o filemode.o version.o \
! $(RTAPELIB) dirname.o idcache.o makepath.o xmalloc.o stripslash.o \
  userspec.o xstrdup.o @LIBOBJS@ @FNMATCH@ @ALLOCA@ 
  # mt source files not shared with cpio.
  MT_SRCS = mt.c argmatch.c
  MT_OBJS = mt.o argmatch.o error.o getopt.o getopt1.o \
! xmalloc.o version.o $(RTAPELIB) @ALLOCA@
  HDRS = cpio.h cpiohdr.h tar.h tarhdr.h defer.h dstring.h extern.h filetypes.h \
  system.h fnmatch.h getopt.h rmt.h safe-stat.h
--- 105,115 ----
  OBJS = copyin.o copyout.o copypass.o defer.o dstring.o global.o \
  main.o tar.o util.o error.o getopt.o getopt1.o filemode.o version.o \
! $(RTAPELIB) rexec.o ruserpass.o \
! dirname.o idcache.o makepath.o xmalloc.o stripslash.o \
  userspec.o xstrdup.o @LIBOBJS@ @FNMATCH@ @ALLOCA@ 
  # mt source files not shared with cpio.
  MT_SRCS = mt.c argmatch.c
  MT_OBJS = mt.o argmatch.o error.o getopt.o getopt1.o \
! xmalloc.o version.o $(RTAPELIB) rexec.o ruserpass.o @ALLOCA@
  HDRS = cpio.h cpiohdr.h tar.h tarhdr.h defer.h dstring.h extern.h filetypes.h \
  system.h fnmatch.h getopt.h rmt.h safe-stat.h
*************** uninstall-info:
*** 198,216 ****
  
  clean:
! 	rm -f cpio rmt mt *.o core
  
  mostlyclean: clean
  
  distclean: clean
! 	rm -f Makefile config.status config.log cpio.info
  
  maintainer-clean: distclean
  	@echo "This command is intended only for maintainers to use;"
  	@echo "rebuilding the deleted files may require special tools."
! 	rm -f TAGS
  
  dist: $(DISTFILES)
  	echo cpio-`sed -e '/version_string/!d' -e 's/[^0-9.]*\([0-9.]*\).*/\1/' -e q version.c` > .fname
! 	rm -rf `cat .fname`
  	mkdir `cat .fname`
  	-ln $(DISTFILES) `cat .fname`
--- 199,217 ----
  
  clean:
! 	-rm -f cpio rmt mt *.o core
  
  mostlyclean: clean
  
  distclean: clean
! 	-rm -f Makefile config.status config.cache config.log cpio.info
  
  maintainer-clean: distclean
  	@echo "This command is intended only for maintainers to use;"
  	@echo "rebuilding the deleted files may require special tools."
! 	-rm -f TAGS
  
  dist: $(DISTFILES)
  	echo cpio-`sed -e '/version_string/!d' -e 's/[^0-9.]*\([0-9.]*\).*/\1/' -e q version.c` > .fname
! 	-rm -rf `cat .fname`
  	mkdir `cat .fname`
  	-ln $(DISTFILES) `cat .fname`
*************** dist: $(DISTFILES)
*** 219,223 ****
  	done
  	tar chzf `cat .fname`.tar.gz `cat .fname`
! 	rm -rf `cat .fname` .fname
  
  # Prevent GNU make v3 from overflowing arg limit on SysV.
--- 220,224 ----
  	done
  	tar chzf `cat .fname`.tar.gz `cat .fname`
! 	-rm -rf `cat .fname` .fname
  
  # Prevent GNU make v3 from overflowing arg limit on SysV.
diff -rc2pP src/cpio-2.4.2/configure.in powerpc-lynxos-2.4/cpio-2.4.2/configure.in
*** src/cpio-2.4.2/configure.in	Wed Dec 20 08:28:29 1995
--- powerpc-lynxos-2.4/cpio-2.4.2/configure.in	Fri Aug 23 10:14:56 1996
*************** AC_CHECK_HEADER(sys/mtio.h,
*** 18,21 ****
--- 18,22 ----
  PROGS="$PROGS mt"
  AC_TRY_CPP([#include <sgtty.h>
+ #include <sys/types.h>
  #include <sys/socket.h>], PROGS="$PROGS rmt")])
  
*************** else
*** 59,63 ****
  fi
  AC_SUBST(FNMATCH)
! AC_CHECK_FUNCS(strerror lchown)
  AC_FUNC_VPRINTF
  AC_FUNC_ALLOCA
--- 60,64 ----
  fi
  AC_SUBST(FNMATCH)
! AC_CHECK_FUNCS(strerror lchown rexec ruserpass)
  AC_FUNC_VPRINTF
  AC_FUNC_ALLOCA
*************** AC_HEADER_DIRENT
*** 65,67 ****
--- 66,70 ----
  AC_CHECK_LIB(nsl, gethostname, [LIBS="$LIBS -lnsl"])
  AC_CHECK_LIB(socket, setsockopt, [LIBS="$LIBS -lsocket"])
+ # The following is only needed for LynxOS
+ AC_CHECK_LIB(bsd, getservbyname, [LIBS="$LIBS -lbsd"])
  AC_OUTPUT(Makefile)
diff -rc2pP src/cpio-2.4.2/rexec.c powerpc-lynxos-2.4/cpio-2.4.2/rexec.c
*** src/cpio-2.4.2/rexec.c	Wed Dec 31 16:00:00 1969
--- powerpc-lynxos-2.4/cpio-2.4.2/rexec.c	Fri Aug 23 10:14:56 1996
***************
*** 0 ****
--- 1,180 ----
+ /*
+  * Copyright (c) 1980, 1993
+  *	The Regents of the University of California.  All rights reserved.
+  *
+  * Redistribution and use in source and binary forms, with or without
+  * modification, are permitted provided that the following conditions
+  * are met:
+  * 1. Redistributions of source code must retain the above copyright
+  *    notice, this list of conditions and the following disclaimer.
+  * 2. Redistributions in binary form must reproduce the above copyright
+  *    notice, this list of conditions and the following disclaimer in the
+  *    documentation and/or other materials provided with the distribution.
+  * 3. All advertising materials mentioning features or use of this software
+  *    must display the following acknowledgement:
+  *	This product includes software developed by the University of
+  *	California, Berkeley and its contributors.
+  * 4. Neither the name of the University nor the names of its contributors
+  *    may be used to endorse or promote products derived from this software
+  *    without specific prior written permission.
+  *
+  * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
+  * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+  * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+  * ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
+  * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+  * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+  * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+  * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+  * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+  * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+  * SUCH DAMAGE.
+  */
+ 
+ #if defined(LIBC_SCCS) && !defined(lint)
+ static char sccsid[] = "@(#)rexec.c	8.1 (Berkeley) 6/4/93";
+ #endif /* LIBC_SCCS and not lint */
+ 
+ #if !defined(HAVE_REXEC)
+ #include <sys/types.h>
+ #include <stdio.h>
+ #include <errno.h>
+ #include <sys/socket.h>
+ #include <netinet/in.h>
+ #include <netdb.h>
+ 
+ #if HAVE_NL_TYPES_H
+ #define NLS
+ #include <nl_types.h>
+ #endif
+ 
+ int	rexecoptions;
+ 
+ int
+ rexec(ahost, rport, name, pass, cmd, fd2p)
+ 	char **ahost;
+ 	int rport;
+ 	const char *name, *pass, *cmd;
+ 	int *fd2p;
+ {
+ 	int s, timo = 1, s3;
+ 	struct sockaddr_in sin, sin2, from;
+ 	char c;
+ 	u_short port;
+ 	struct hostent *hp;
+ 	static char savename[256];
+ 
+ #if NLS
+ 	libc_nls_init();
+ #endif
+ 	hp = gethostbyname(*ahost);
+ 	if (hp == 0) {
+ #if NLS
+ 		fprintf(stderr, "%s: %s\n", *ahost,
+                               catgets(_libc_cat, HerrorListSet,
+ 				      2, "unknown host"));
+ #else
+ 		fprintf(stderr, "%s: unknown host\n", *ahost);
+ #endif
+ 		return (-1);
+ 	}
+ 	sin.sin_family = hp->h_addrtype;
+ 	sin.sin_port = rport;
+ 	memcpy ((caddr_t)&sin.sin_addr, hp->h_addr, hp->h_length);
+ 	strncpy((*ahost = savename), hp->h_name, sizeof(savename) -1);
+ 	ruserpass(*ahost, &name, &pass);
+ retry:
+ 	s = socket(AF_INET, SOCK_STREAM, 0);
+ 	if (s < 0) {
+ #if NLS
+ 		perror(catgets(_libc_cat, NetMiscSet,
+ 			       NetMiscRexecSocket,
+ 			       "rcmd: socket"));
+ #else
+ 		perror("rexec: socket");
+ #endif
+ 		return (-1);
+ 	}
+ 	if (connect(s, (struct sockaddr *)&sin, sizeof(sin)) < 0) {
+ 		if (errno == ECONNREFUSED && timo <= 16) {
+ 			(void) close(s);
+ 			sleep(timo);
+ 			timo *= 2;
+ 			goto retry;
+ 		}
+ 		perror(*ahost);
+ 		return (-1);
+ 	}
+ 	if (fd2p == 0) {
+ 		(void) write(s, "", 1);
+ 		port = 0;
+ 	} else {
+ 		char num[8];
+ 		int s2, sin2len;
+ 		
+ 		s2 = socket(AF_INET, SOCK_STREAM, 0);
+ 		if (s2 < 0) {
+ 			(void) close(s);
+ 			return (-1);
+ 		}
+ 		sin2len = sizeof (sin2);
+ 		sin2.sin_addr.s_addr = INADDR_ANY;
+ 		sin2.sin_family = sin.sin_family;
+ 		bind(s2, (void*) &sin2, sin2len);
+ 		listen(s2, 1);
+ 		if (getsockname(s2, (struct sockaddr *)&sin2, &sin2len) < 0 ||
+ 		  sin2len != sizeof (sin2)) {
+ #if NLS
+ 			perror(catgets(_libc_cat, NetMiscSet,
+ 				       NetMiscGetsockname,
+ 				       "getsockname"));
+ #else
+ 			perror("getsockname");
+ #endif
+ 			(void) close(s2);
+ 			goto bad;
+ 		}
+ 		port = ntohs((u_short)sin2.sin_port);
+ 		(void) sprintf(num, "%u", port);
+ 		(void) write(s, num, strlen(num)+1);
+ 		{ int len = sizeof (from);
+ 		  s3 = accept(s2, (struct sockaddr *)&from, &len);
+ 		  close(s2);
+ 		  if (s3 < 0) {
+ #if NLS
+ 			perror(catgets(_libc_cat, NetMiscSet,
+ 				       NetMiscAccept,
+ 				       "accept"));
+ #else
+ 			perror("accept");
+ #endif
+ 			port = 0;
+ 			goto bad;
+ 		  }
+ 		}
+ 		*fd2p = s3;
+ 	}
+ 	(void) write(s, name, strlen(name) + 1);
+ 	/* should public key encypt the password here */
+ 	(void) write(s, pass, strlen(pass) + 1);
+ 	(void) write(s, cmd, strlen(cmd) + 1);
+ 	if (read(s, &c, 1) != 1) {
+ 		perror(*ahost);
+ 		goto bad;
+ 	}
+ 	if (c != 0) {
+ 		while (read(s, &c, 1) == 1) {
+ 			(void) write(2, &c, 1);
+ 			if (c == '\n')
+ 				break;
+ 		}
+ 		goto bad;
+ 	}
+ 	return (s);
+ bad:
+ 	if (port)
+ 		(void) close(*fd2p);
+ 	(void) close(s);
+ 	return (-1);
+ }
+ #endif /* !defined(HAVE_REXEC) */
diff -rc2pP src/cpio-2.4.2/ruserpass.c powerpc-lynxos-2.4/cpio-2.4.2/ruserpass.c
*** src/cpio-2.4.2/ruserpass.c	Wed Dec 31 16:00:00 1969
--- powerpc-lynxos-2.4/cpio-2.4.2/ruserpass.c	Fri Aug 23 10:14:56 1996
***************
*** 0 ****
--- 1,940 ----
+ /*
+  * Copyright (c) 1983 Regents of the University of California.
+  * All rights reserved.
+  *
+  * Redistribution and use in source and binary forms are permitted
+  * provided that the above copyright notice and this paragraph are
+  * duplicated in all such forms and that any documentation,
+  * advertising materials, and other materials related to such
+  * distribution and use acknowledge that the software was developed
+  * by the University of California, Berkeley.  The name of the
+  * University may not be used to endorse or promote products derived
+  * from this software without specific prior written permission.
+  * THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR
+  * IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
+  * WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.
+  */
+ 
+ #if defined(LIBC_SCCS) && !defined(lint)
+ static char sccsid[] = "@(#)ruserpass.c	5.5 (Berkeley) 6/27/88";
+ #endif /* LIBC_SCCS and not lint */
+ 
+ #if !defined(HAVE_RUSERPASS)
+ #include <sys/types.h>
+ #include <sys/stat.h>
+ #include <utmp.h>
+ #include <pwd.h>
+ #include <errno.h>
+ #include <netdb.h>
+ #include <string.h>
+ #include <stdlib.h>
+ 
+ static void renv(const char *host, char **aname, char **apass);
+ static char * renvlook(const char *host);
+ static struct utmp *getutmp(char *sttyname);
+ static	FILE *cfile;
+ static void rnetrc(const char *host, char **aname, char **apass);
+ static void mkpwclear(char *spasswd, char mch, char *sencpasswd);
+ static int token();
+ 
+ extern char *getlogin();
+ extern char *getpass();
+ extern char *ttyname();
+ 
+ #define index strchr
+ #define rindex strrchr
+ 
+ #ifndef _PATH_UTMP
+ #define _PATH_UTMP UTMP
+ #endif
+ 
+ #if HAVE_NL_TYPES_H
+ #define NLS
+ #include <nl_types.h>
+ #endif
+ 
+ void
+ ruserpass(const char *host, char **aname, char **apass)
+ {
+ 	static char namebuf [256];
+ 	struct hostent *hp;
+ 	char    name[256]; /* a temp name buffer to avoid overlayyed */
+ 
+ #if NLS
+ 	libc_nls_init();
+ #endif
+ 	strncpy(name, host, sizeof(name) - 1);
+ 
+ 	if (hp = gethostbyname (name))
+ 		strncpy(name,hp->h_name, sizeof(name) - 1);
+ 	renv(name, aname, apass);
+ 	if (*aname == 0 || *apass == 0)
+ 		rnetrc(name, aname, apass); /*rnetrc would call gethostbyname */
+ 	if (*aname == 0) {
+ 		*aname = getlogin();
+ 		if (*aname == NULL) {
+ 			struct passwd *pp = getpwuid(getuid());
+ 			if (pp != NULL)
+ 				*aname = pp->pw_name;
+ 		}
+ #if NLS
+ 		printf("%s (%s:%s): ",
+ 		       catgets(_libc_cat, NetMiscSet, NetMiscName, "Name"),
+ 		       host, *aname);
+ #else
+ 		printf("Name (%s:%s): ", host, *aname);
+ #endif
+ 		fflush(stdout);
+ 		if (read(2, namebuf, sizeof (namebuf)) <= 0) {
+ 			perror ("read");
+ 			exit(1);
+ 		}
+ 		if (namebuf [0] != '\n') {
+ 			char *ptr;
+ 			*aname = namebuf;
+ 			namebuf [sizeof (namebuf) - 1] = '0';
+ 			if (ptr = index(namebuf, '\n'))
+ 				*ptr = 0;
+ 		}
+ 	}
+ 	if (*aname && *apass == 0) {
+ #if NLS
+ 		printf("%s (%s:%s): ",
+ 		       catgets(_libc_cat, NetMiscSet, NetMiscPassword, "Password"),
+ 		       host, *aname);
+ #else
+ 		printf("Password (%s:%s): ", host, *aname);
+ #endif
+ 		fflush(stdout);
+ 		*apass = getpass("");
+ 	}
+ }
+ 
+ static void
+ renv(const char *host, char **aname, char **apass)
+ {
+ 	register char *cp;
+ 	char *comma;
+ 
+ 	cp = renvlook(host);
+ 	if (cp == NULL)
+ 		return;
+ 	if (!isalpha(cp[0]))
+ 		return;
+ 	comma = index(cp, ',');
+ 	if (comma == 0)
+ 		return;
+ 	if (*aname == 0) {
+ 		*aname = malloc(comma - cp + 1);
+ 		strncpy(*aname, cp, comma - cp);
+ 	} else
+ 		if (strncmp(*aname, cp, comma - cp))
+ 			return;
+ 	comma++;
+ 	cp = malloc(strlen(comma)+1);
+ 	strcpy(cp, comma);
+ 	*apass = malloc(16);
+ 	mkpwclear(cp, host[0], *apass);
+ }
+ 
+ #if !defined(HAVE_GNU_LD) && !defined (__ELF__)
+ #define	__environ	environ
+ #endif
+ 
+ static char *
+ renvlook(const char *host)
+ {
+ 	register char *cp, **env;
+ 	extern char **__environ;
+ 
+ 	for (env = __environ; *env != NULL; env++)
+ 		if (!strncmp(*env, "MACH", 4)) {
+ 			cp = index(*env, '=');
+ 			if (cp == 0)
+ 				continue;
+ 			if (strncmp(*env+4, host, cp-(*env+4)))
+ 				continue;
+ 			return (cp+1);
+ 		}
+ 	return (NULL);
+ }
+ 
+ #define	DEFAULT	1
+ #define	LOGIN	2
+ #define	PASSWD	3
+ #define	NOTIFY	4
+ #define	WRITE	5
+ #define	YES	6
+ #define	NO	7
+ #define	COMMAND	8
+ #define	FORCE	9
+ #define	ID	10
+ #define	MACHINE	11
+ 
+ static char tokval[100];
+ 
+ static struct toktab {
+ 	char *tokstr;
+ 	int tval;
+ } toktab[]= {
+ 	"default",	DEFAULT,
+ 	"login",	LOGIN,
+ 	"password",	PASSWD,
+ 	"notify",	NOTIFY,
+ 	"write",	WRITE,
+ 	"yes",		YES,
+ 	"y",		YES,
+ 	"no",		NO,
+ 	"n",		NO,
+ 	"command",	COMMAND,
+ 	"force",	FORCE,
+ 	"machine",	MACHINE,
+ 	0,		0
+ };
+ 
+ static void
+ rnetrc(const char *host, char **aname, char **apass)
+ {
+ 	char *hdir, buf[BUFSIZ];
+ 	int t;
+ 	struct stat stb;
+ 	struct hostent *hp;
+ 
+ #if NLS
+ 	libc_nls_init();
+ #endif
+ 	hdir = getenv("HOME");
+ 	if (hdir == NULL)
+ 		hdir = ".";
+ 	(void)sprintf(buf, "%s/.netrc", hdir);
+ 	cfile = fopen(buf, "r");
+ 	if (cfile == NULL) {
+ 		if (errno != ENOENT)
+ 			perror(buf);
+ 		return;
+ 	}
+ next:
+ 	while ((t = token())) switch(t) {
+ 
+ 	case DEFAULT:
+ 		(void) token();
+ 		continue;
+ 
+ 	case MACHINE:
+ 		if (token() != ID)
+ 			continue;
+ 		if(hp = gethostbyname (tokval))
+ 		{
+ 			if (strcmp(host, hp->h_name))
+ 				continue;
+ 		}
+ 		else
+ 			if (strcmp(host, tokval))
+ 				continue;
+ 		while ((t = token()) && t != MACHINE) switch(t) {
+ 
+ 		case LOGIN:
+ 			if (token())
+ 				if (*aname == 0) { 
+ 					*aname = malloc(strlen(tokval) + 1);
+ 					strcpy(*aname, tokval);
+ 				} else {
+ 					if (strcmp(*aname, tokval))
+ 						goto next;
+ 				}
+ 			break;
+ 		case PASSWD:
+ 			if (fstat(fileno(cfile), &stb) >= 0
+ 			    && (stb.st_mode & 077) != 0) {
+ #if NLS
+ 	fprintf(stderr, "%s\n", catgets(_libc_cat, NetMiscSet,
+ 				NetMiscNetrcWrongPasswordMode,
+ 				"Error - .netrc file not correct mode.\n\
+ 				 Remove password or correct mode."));
+ #else
+ 	fprintf(stderr, "Error - .netrc file not correct mode.\n");
+ 	fprintf(stderr, "Remove password or correct mode.\n");
+ #endif
+ 				exit(1);
+ 			}
+ 			if (token() && *apass == 0) {
+ 				*apass = malloc(strlen(tokval) + 1);
+ 				strcpy(*apass, tokval);
+ 			}
+ 			break;
+ 		case COMMAND:
+ 		case NOTIFY:
+ 		case WRITE:
+ 		case FORCE:
+ 			(void) token();
+ 			break;
+ 		default:
+ #if NLS
+ 	fprintf(stderr, "%s %s\n",
+ 		catgets(_libc_cat, NetMiscSet,
+ 			NetMiscUnknownNetrcOption,
+ 			"Unknown .netrc option"),
+ 		tokval);
+ #else
+ 	fprintf(stderr, "Unknown .netrc option %s\n", tokval);
+ #endif
+ 			break;
+ 		}
+ 		goto done;
+ 	}
+ done:
+ 	fclose(cfile);
+ }
+ 
+ static int
+ token()
+ {
+ 	char *cp;
+ 	int c;
+ 	struct toktab *t;
+ 
+ 	if (feof(cfile))
+ 		return (0);
+ #if defined(_POSIX_THREAD_SAFE_FUNCTIONS) || defined(_REENTRANT)
+ #undef getc
+ #define getc	getc_unlocked
+ 	flockfile (cfile);
+ #endif
+ 	while ((c = getc(cfile)) != EOF &&
+ 	    (c == '\n' || c == '\t' || c == ' ' || c == ','))
+ 		continue;
+ 	if (c == EOF)
+ 		return (0);
+ 	cp = tokval;
+ 	if (c == '"') {
+ 		while ((c = getc(cfile)) != EOF && c != '"') {
+ 			if (c == '\\')
+ 				c = getc(cfile);
+ 			*cp++ = c;
+ 		}
+ 	} else {
+ 		*cp++ = c;
+ 		while ((c = getc(cfile)) != EOF
+ 		    && c != '\n' && c != '\t' && c != ' ' && c != ',') {
+ 			if (c == '\\')
+ 				c = getc(cfile);
+ 			*cp++ = c;
+ 		}
+ 	}
+ #if defined(_POSIX_THREAD_SAFE_FUNCTIONS) || defined(_REENTRANT)
+ 	funlockfile (cfile);
+ #endif
+ 	*cp = 0;
+ 	if (tokval[0] == 0)
+ 		return (0);
+ 	for (t = toktab; t->tokstr; t++)
+ 		if (!strcmp(t->tokstr, tokval))
+ 			return (t->tval);
+ 	return (ID);
+ }
+ 
+ /* rest is nbs.c stolen from berknet */
+ 
+ #if 0
+ static char *nbsencrypt(char *str, char *key, char *result);
+ static char *nbs8encrypt(char *str, char *key);
+ static char *deblknot(char *blk);
+ #endif
+ 
+ static char *nbsdecrypt(char *cpt, char *key, char *result);
+ static char *nbs8decrypt(char *crp, char *key);
+ static void enblkclr(char *blk, char *str);
+ static char *deblkclr(char *blk);
+ static void enblknot(char *blk, char *crp);
+ static void nbssetkey(char *key);
+ static void blkencrypt(char *block, int edflag);
+ 
+ static char	E[48];
+ 
+ /*
+  * The E bit-selection table.
+  */
+ static char	e[] = {
+ 	32, 1, 2, 3, 4, 5,
+ 	 4, 5, 6, 7, 8, 9,
+ 	 8, 9,10,11,12,13,
+ 	12,13,14,15,16,17,
+ 	16,17,18,19,20,21,
+ 	20,21,22,23,24,25,
+ 	24,25,26,27,28,29,
+ 	28,29,30,31,32, 1,
+ };
+ 
+ #if 0
+ static
+ char *nbsencrypt(str,key,result)
+   char *str, *key;
+   char *result;
+ {
+ 	static char buf[20],oldbuf[20];
+ 	register int j;
+ 	result[0] = 0;
+ 	strcpy(oldbuf,key);
+ 	while(*str){
+ 		for(j=0;j<10;j++)buf[j] = 0;
+ 		for(j=0;j<8 && *str;j++)buf[j] = *str++;
+ 		strcat(result,nbs8encrypt(buf,oldbuf));
+ 		strcat(result,"$");
+ 		strcpy(oldbuf,buf);
+ 		}
+ 	return(result);
+ }
+ 
+ #endif
+ 
+ static
+ char *nbsdecrypt(cpt,key,result)
+   char *cpt,*key;
+   char *result;
+ {
+ 	char *s;
+ 	char c,oldbuf[20];
+ 	result[0] = 0;
+ 	strcpy(oldbuf,key);
+ 	while(*cpt){
+ 		for(s = cpt;*s && *s != '$';s++);
+ 		c = *s;
+ 		*s = 0;
+ 		strcpy(oldbuf,nbs8decrypt(cpt,oldbuf));
+ 		strcat(result,oldbuf);
+ 		if(c == 0)break;
+ 		cpt = s + 1;
+ 		}
+ 	return(result);
+ }
+ 
+ #if 0
+ static
+ char *nbs8encrypt(str,key)
+ char *str, *key;
+ {
+ 	static char keyblk[100], blk[100];
+ 	register int i;
+ 
+ 	enblkclr(keyblk,key);
+ 	nbssetkey(keyblk);
+ 
+ 	for(i=0;i<48;i++) E[i] = e[i];
+ 	enblkclr(blk,str);
+ 	blkencrypt(blk,0);			/* forward dir */
+ 
+ 	return(deblknot(blk));
+ }
+ 
+ #endif
+ 
+ static
+ char *nbs8decrypt(crp,key)
+ char *crp, *key;
+ {
+ 	static char keyblk[100], blk[100];
+ 	register int i;
+ 
+ 	enblkclr(keyblk,key);
+ 	nbssetkey(keyblk);
+ 
+ 	for(i=0;i<48;i++) E[i] = e[i];
+ 	enblknot(blk,crp);
+ 	blkencrypt(blk,1);			/* backward dir */
+ 
+ 	return(deblkclr(blk));
+ }
+ 
+ static void
+ enblkclr(blk,str)	/* ignores top bit of chars in string str */
+ char *blk,*str;
+ {
+ 	register int i,j;
+ 	char c;
+ 	for(i=0;i<70;i++)blk[i] = 0;
+ 	for(i=0; (c= *str) && i<64; str++){
+ 		for(j=0; j<7; j++, i++)
+ 			blk[i] = (c>>(6-j)) & 01;
+ 		i++;
+ 		}
+ }
+ 
+ static
+ char *deblkclr(blk)
+ char *blk;
+ {
+ 	register int i,j;
+ 	char c;
+ 	static char iobuf[30];
+ 	for(i=0; i<10; i++){
+ 		c = 0;
+ 		for(j=0; j<7; j++){
+ 			c <<= 1;
+ 			c |= blk[8*i+j];
+ 			}
+ 		iobuf[i] = c;
+ 	}
+ 	iobuf[i] = 0;
+ 	return(iobuf);
+ }
+ 
+ static void
+ enblknot(blk,crp)
+ char *blk;
+ char *crp;
+ {
+ 	register int i,j;
+ 	char c;
+ 	for(i=0;i<70;i++)blk[i] = 0;
+ 	for(i=0; (c= *crp) && i<64; crp++){
+ 		if(c>'Z') c -= 6;
+ 		if(c>'9') c -= 7;
+ 		c -= '.';
+ 		for(j=0; j<6; j++, i++)
+ 			blk[i] = (c>>(5-j)) & 01;
+ 		}
+ }
+ 
+ #if 0
+ static
+ char *deblknot(blk)
+ char *blk;
+ {
+ 	register int i,j;
+ 	char c;
+ 	static char iobuf[30];
+ 	for(i=0; i<11; i++){
+ 		c = 0;
+ 		for(j=0; j<6; j++){
+ 			c <<= 1;
+ 			c |= blk[6*i+j];
+ 			}
+ 		c += '.';
+ 		if(c > '9')c += 7;
+ 		if(c > 'Z')c += 6;
+ 		iobuf[i] = c;
+ 	}
+ 	iobuf[i] = 0;
+ 	return(iobuf);
+ }
+ #endif
+ 
+ 
+ /*
+  * This program implements the
+  * Proposed Federal Information Processing
+  *  Data Encryption Standard.
+  * See Federal Register, March 17, 1975 (40FR12134)
+  */
+ 
+ /*
+  * Initial permutation,
+  */
+ static	char	IP[] = {
+ 	58,50,42,34,26,18,10, 2,
+ 	60,52,44,36,28,20,12, 4,
+ 	62,54,46,38,30,22,14, 6,
+ 	64,56,48,40,32,24,16, 8,
+ 	57,49,41,33,25,17, 9, 1,
+ 	59,51,43,35,27,19,11, 3,
+ 	61,53,45,37,29,21,13, 5,
+ 	63,55,47,39,31,23,15, 7,
+ };
+ 
+ /*
+  * Final permutation, FP = IP^(-1)
+  */
+ static	char	FP[] = {
+ 	40, 8,48,16,56,24,64,32,
+ 	39, 7,47,15,55,23,63,31,
+ 	38, 6,46,14,54,22,62,30,
+ 	37, 5,45,13,53,21,61,29,
+ 	36, 4,44,12,52,20,60,28,
+ 	35, 3,43,11,51,19,59,27,
+ 	34, 2,42,10,50,18,58,26,
+ 	33, 1,41, 9,49,17,57,25,
+ };
+ 
+ /*
+  * Permuted-choice 1 from the key bits
+  * to yield C and D.
+  * Note that bits 8,16... are left out:
+  * They are intended for a parity check.
+  */
+ static	char	PC1_C[] = {
+ 	57,49,41,33,25,17, 9,
+ 	 1,58,50,42,34,26,18,
+ 	10, 2,59,51,43,35,27,
+ 	19,11, 3,60,52,44,36,
+ };
+ 
+ static	char	PC1_D[] = {
+ 	63,55,47,39,31,23,15,
+ 	 7,62,54,46,38,30,22,
+ 	14, 6,61,53,45,37,29,
+ 	21,13, 5,28,20,12, 4,
+ };
+ 
+ /*
+  * Sequence of shifts used for the key schedule.
+ */
+ static	char	shifts[] = {
+ 	1,1,2,2,2,2,2,2,1,2,2,2,2,2,2,1,
+ };
+ 
+ /*
+  * Permuted-choice 2, to pick out the bits from
+  * the CD array that generate the key schedule.
+  */
+ static	char	PC2_C[] = {
+ 	14,17,11,24, 1, 5,
+ 	 3,28,15, 6,21,10,
+ 	23,19,12, 4,26, 8,
+ 	16, 7,27,20,13, 2,
+ };
+ 
+ static	char	PC2_D[] = {
+ 	41,52,31,37,47,55,
+ 	30,40,51,45,33,48,
+ 	44,49,39,56,34,53,
+ 	46,42,50,36,29,32,
+ };
+ 
+ /*
+  * The C and D arrays used to calculate the key schedule.
+  */
+ 
+ static	char	C[28];
+ static	char	D[28];
+ /*
+  * The key schedule.
+  * Generated from the key.
+  */
+ static	char	KS[16][48];
+ 
+ /*
+  * Set up the key schedule from the key.
+  */
+ 
+ static void
+ nbssetkey(key)
+ char *key;
+ {
+ 	register i, j, k;
+ 	int t;
+ 
+ 	/*
+ 	 * First, generate C and D by permuting
+ 	 * the key.  The low order bit of each
+ 	 * 8-bit char is not used, so C and D are only 28
+ 	 * bits apiece.
+ 	 */
+ 	for (i=0; i<28; i++) {
+ 		C[i] = key[PC1_C[i]-1];
+ 		D[i] = key[PC1_D[i]-1];
+ 	}
+ 	/*
+ 	 * To generate Ki, rotate C and D according
+ 	 * to schedule and pick up a permutation
+ 	 * using PC2.
+ 	 */
+ 	for (i=0; i<16; i++) {
+ 		/*
+ 		 * rotate.
+ 		 */
+ 		for (k=0; k<shifts[i]; k++) {
+ 			t = C[0];
+ 			for (j=0; j<28-1; j++)
+ 				C[j] = C[j+1];
+ 			C[27] = t;
+ 			t = D[0];
+ 			for (j=0; j<28-1; j++)
+ 				D[j] = D[j+1];
+ 			D[27] = t;
+ 		}
+ 		/*
+ 		 * get Ki. Note C and D are concatenated.
+ 		 */
+ 		for (j=0; j<24; j++) {
+ 			KS[i][j] = C[PC2_C[j]-1];
+ 			KS[i][j+24] = D[PC2_D[j]-28-1];
+ 		}
+ 	}
+ }
+ 
+ 
+ /*
+  * The 8 selection functions.
+  * For some reason, they give a 0-origin
+  * index, unlike everything else.
+  */
+ static	char	S[8][64] = {
+ 	14, 4,13, 1, 2,15,11, 8, 3,10, 6,12, 5, 9, 0, 7,
+ 	 0,15, 7, 4,14, 2,13, 1,10, 6,12,11, 9, 5, 3, 8,
+ 	 4, 1,14, 8,13, 6, 2,11,15,12, 9, 7, 3,10, 5, 0,
+ 	15,12, 8, 2, 4, 9, 1, 7, 5,11, 3,14,10, 0, 6,13,
+ 
+ 	15, 1, 8,14, 6,11, 3, 4, 9, 7, 2,13,12, 0, 5,10,
+ 	 3,13, 4, 7,15, 2, 8,14,12, 0, 1,10, 6, 9,11, 5,
+ 	 0,14, 7,11,10, 4,13, 1, 5, 8,12, 6, 9, 3, 2,15,
+ 	13, 8,10, 1, 3,15, 4, 2,11, 6, 7,12, 0, 5,14, 9,
+ 
+ 	10, 0, 9,14, 6, 3,15, 5, 1,13,12, 7,11, 4, 2, 8,
+ 	13, 7, 0, 9, 3, 4, 6,10, 2, 8, 5,14,12,11,15, 1,
+ 	13, 6, 4, 9, 8,15, 3, 0,11, 1, 2,12, 5,10,14, 7,
+ 	 1,10,13, 0, 6, 9, 8, 7, 4,15,14, 3,11, 5, 2,12,
+ 
+ 	 7,13,14, 3, 0, 6, 9,10, 1, 2, 8, 5,11,12, 4,15,
+ 	13, 8,11, 5, 6,15, 0, 3, 4, 7, 2,12, 1,10,14, 9,
+ 	10, 6, 9, 0,12,11, 7,13,15, 1, 3,14, 5, 2, 8, 4,
+ 	 3,15, 0, 6,10, 1,13, 8, 9, 4, 5,11,12, 7, 2,14,
+ 
+ 	 2,12, 4, 1, 7,10,11, 6, 8, 5, 3,15,13, 0,14, 9,
+ 	14,11, 2,12, 4, 7,13, 1, 5, 0,15,10, 3, 9, 8, 6,
+ 	 4, 2, 1,11,10,13, 7, 8,15, 9,12, 5, 6, 3, 0,14,
+ 	11, 8,12, 7, 1,14, 2,13, 6,15, 0, 9,10, 4, 5, 3,
+ 
+ 	12, 1,10,15, 9, 2, 6, 8, 0,13, 3, 4,14, 7, 5,11,
+ 	10,15, 4, 2, 7,12, 9, 5, 6, 1,13,14, 0,11, 3, 8,
+ 	 9,14,15, 5, 2, 8,12, 3, 7, 0, 4,10, 1,13,11, 6,
+ 	 4, 3, 2,12, 9, 5,15,10,11,14, 1, 7, 6, 0, 8,13,
+ 
+ 	 4,11, 2,14,15, 0, 8,13, 3,12, 9, 7, 5,10, 6, 1,
+ 	13, 0,11, 7, 4, 9, 1,10,14, 3, 5,12, 2,15, 8, 6,
+ 	 1, 4,11,13,12, 3, 7,14,10,15, 6, 8, 0, 5, 9, 2,
+ 	 6,11,13, 8, 1, 4,10, 7, 9, 5, 0,15,14, 2, 3,12,
+ 
+ 	13, 2, 8, 4, 6,15,11, 1,10, 9, 3,14, 5, 0,12, 7,
+ 	 1,15,13, 8,10, 3, 7, 4,12, 5, 6,11, 0,14, 9, 2,
+ 	 7,11, 4, 1, 9,12,14, 2, 0, 6,10,13,15, 3, 5, 8,
+ 	 2, 1,14, 7, 4,10, 8,13,15,12, 9, 0, 3, 5, 6,11,
+ };
+ 
+ /*
+  * P is a permutation on the selected combination
+  * of the current L and key.
+  */
+ static	char	P[] = {
+ 	16, 7,20,21,
+ 	29,12,28,17,
+ 	 1,15,23,26,
+ 	 5,18,31,10,
+ 	 2, 8,24,14,
+ 	32,27, 3, 9,
+ 	19,13,30, 6,
+ 	22,11, 4,25,
+ };
+ 
+ /*
+  * The current block, divided into 2 halves.
+  */
+ static	char	L[32], R[32];
+ static	char	tempL[32];
+ static	char	f[32];
+ 
+ /*
+  * The combination of the key and the input, before selection.
+  */
+ static	char	preS[48];
+ 
+ /*
+  * The payoff: encrypt a block.
+  */
+ 
+ static void
+ blkencrypt(char *block, int edflag)
+ {
+ 	int i, ii;
+ 	register t, j, k;
+ 
+ 	/*
+ 	 * First, permute the bits in the input
+ 	 */
+ 	for (j=0; j<64; j++)
+ 		L[j] = block[IP[j]-1];
+ 	/*
+ 	 * Perform an encryption operation 16 times.
+ 	 */
+ 	for (ii=0; ii<16; ii++) {
+ 		/*
+ 		 * Set direction
+ 		 */
+ 		if (edflag)
+ 			i = 15-ii;
+ 		else
+ 			i = ii;
+ 		/*
+ 		 * Save the R array,
+ 		 * which will be the new L.
+ 		 */
+ 		for (j=0; j<32; j++)
+ 			tempL[j] = R[j];
+ 		/*
+ 		 * Expand R to 48 bits using the E selector;
+ 		 * exclusive-or with the current key bits.
+ 		 */
+ 		for (j=0; j<48; j++)
+ 			preS[j] = R[E[j]-1] ^ KS[i][j];
+ 		/*
+ 		 * The pre-select bits are now considered
+ 		 * in 8 groups of 6 bits each.
+ 		 * The 8 selection functions map these
+ 		 * 6-bit quantities into 4-bit quantities
+ 		 * and the results permuted
+ 		 * to make an f(R, K).
+ 		 * The indexing into the selection functions
+ 		 * is peculiar; it could be simplified by
+ 		 * rewriting the tables.
+ 		 */
+ 		for (j=0; j<8; j++) {
+ 			t = 6*j;
+ 			k = S[j][(preS[t+0]<<5)+
+ 				(preS[t+1]<<3)+
+ 				(preS[t+2]<<2)+
+ 				(preS[t+3]<<1)+
+ 				(preS[t+4]<<0)+
+ 				(preS[t+5]<<4)];
+ 			t = 4*j;
+ 			f[t+0] = (k>>3)&01;
+ 			f[t+1] = (k>>2)&01;
+ 			f[t+2] = (k>>1)&01;
+ 			f[t+3] = (k>>0)&01;
+ 		}
+ 		/*
+ 		 * The new R is L ^ f(R, K).
+ 		 * The f here has to be permuted first, though.
+ 		 */
+ 		for (j=0; j<32; j++)
+ 			R[j] = L[j] ^ f[P[j]-1];
+ 		/*
+ 		 * Finally, the new L (the original R)
+ 		 * is copied back.
+ 		 */
+ 		for (j=0; j<32; j++)
+ 			L[j] = tempL[j];
+ 	}
+ 	/*
+ 	 * The output L and R are reversed.
+ 	 */
+ 	for (j=0; j<32; j++) {
+ 		t = L[j];
+ 		L[j] = R[j];
+ 		R[j] = t;
+ 	}
+ 	/*
+ 	 * The final output
+ 	 * gets the inverse permutation of the very original.
+ 	 */
+ 	for (j=0; j<64; j++)
+ 		block[j] = L[FP[j]-1];
+ }
+ /*
+ 	getutmp()
+ 	return a pointer to the system utmp structure associated with
+ 	terminal sttyname, e.g. "/dev/tty3"
+ 	Is version independent-- will work on v6 systems
+ 	return NULL if error
+ */
+ static
+ struct utmp *getutmp(char *sttyname)
+ {
+ 	static struct utmp utmpstr;
+ 	FILE *fdutmp;
+ 
+ 	if(sttyname == NULL || sttyname[0] == 0)return(NULL);
+ 
+ 	fdutmp = fopen(_PATH_UTMP,"r");
+ 	if(fdutmp == NULL)return(NULL);
+ 
+ 	while(fread(&utmpstr,1,sizeof utmpstr,fdutmp) == sizeof utmpstr)
+ 		if(strcmp(utmpstr.ut_line,sttyname+5) == 0){
+ 			fclose(fdutmp);
+ 			return(&utmpstr);
+ 		}
+ 	fclose(fdutmp);
+ 	return(NULL);
+ }
+ 
+ static void
+ sreverse(sto, sfrom)
+ 	register char *sto, *sfrom;
+ {
+ 	register int i;
+ 
+ 	i = strlen(sfrom);
+ 	while (i >= 0)
+ 		*sto++ = sfrom[i--];
+ }
+ 
+ static
+ char *mkenvkey(char mch)
+ {
+ 	static char skey[40];
+ 	register struct utmp *putmp;
+ 	char stemp[40], stemp1[40], sttyname[30];
+ 	register char *sk,*p;
+ 
+ 	if (isatty(2))
+ 		strcpy(sttyname,ttyname(2));
+ 	else if (isatty(0))
+ 		strcpy(sttyname,ttyname(0));
+ 	else if (isatty(1))
+ 		strcpy(sttyname,ttyname(1));
+ 	else
+ 		return (NULL);
+ 	putmp = getutmp(sttyname);
+ 	if (putmp == NULL)
+ 		return (NULL);
+ 	sk = skey;
+ 	p = putmp->ut_line;
+ 	while (*p)
+ 		*sk++ = *p++;
+ 	*sk++ = mch;
+ 	(void)sprintf(stemp, "%ld", putmp->ut_time);
+ 	sreverse(stemp1, stemp);
+ 	p = stemp1;
+ 	while (*p)
+ 		*sk++ = *p++;
+ 	*sk = 0;
+ 	return (skey);
+ }
+ 
+ #if 0
+ static void
+ mkpwunclear(spasswd,mch,sencpasswd)
+ 	char *spasswd, mch, *sencpasswd;
+ {
+ 	register char *skey;
+ 
+ 	if (spasswd[0] == 0) {
+ 		sencpasswd[0] = 0;
+ 		return;
+ 	}
+ 	skey = mkenvkey(mch);
+ 	if (skey == NULL) {
+ 		fprintf(stderr, "Can't make key\n");
+ 		exit(1);
+ 	}
+ 	nbsencrypt(spasswd, skey, sencpasswd);
+ }
+ 
+ #endif
+ 
+ static void
+ mkpwclear(sencpasswd,mch,spasswd)
+ 	char *spasswd, mch, *sencpasswd;
+ {
+ 	register char *skey;
+ 
+ 	if (sencpasswd[0] == 0) {
+ 		spasswd[0] = 0;
+ 		return;
+ 	}
+ 	skey = mkenvkey(mch);
+ 	if (skey == NULL) {
+ 		fprintf(stderr, "Can't make key\n");
+ 		exit(1);
+ 	}
+ 	nbsdecrypt(sencpasswd, skey, spasswd);
+ }
+ #endif /* !defined(HAVE_RUSERPASS) */


From pinard@progiciels-bpi.ca Sun May 17 23:50:35 1998
X-From-Line: nobody Mon Sep 30 12:33:00 1996
Received: by drip.colorado.edu (cu.generic.890828)
Received: from degusse.iro.umontreal.ca (degusse.IRO.UMontreal.CA [132.204.32.45]) by cygnus.com (8.6.12/8.6.9) with ESMTP id KAA15741; Mon, 30 Sep 1996 10:46:13 -0700
Received: (from daemon@localhost) by degusse.iro.umontreal.ca (8.7.5/8.7.3) id NAA16967 for tar-forum-outgoing; Mon, 30 Sep 1996 13:46:00 -0400 (EDT)
Received: from rtsq.grics.qc.ca (root@rtsq.grics.qc.ca [199.84.132.10]) by degusse.iro.umontreal.ca (8.7.5/8.7.3) with ESMTP id NAA16954 for <tar-forum@iro.umontreal.ca>; Mon, 30 Sep 1996 13:45:49 -0400 (EDT)
Received: by rtsq.grics.qc.ca (8.7.5/8.7.3) with UUCP id NAA25100; Mon, 30 Sep 1996 13:51:48 -0400
X-Authentication-Warning: rtsq.grics.qc.ca: uicule set sender to pinard@icule.progiciels-bpi.ca using -f
Received: by icule.progiciels-bpi.ca (8.7.5/8.7.3) id NAA01231; 1996-09-30 13:43:31-04:00
To: GNITS List <gnits@gnu.ai.mit.edu>
Cc: tar-forum@IRO.UMontreal.CA
Subject: Attributes of symbolic links
X-Face: "b_m|CE6#'Q8fliQrwHl9K,]PA_o'*S~Dva{~b1n*)K*A(BIwQW.:LY?t4~xhYka_.LV?Qq
 `}X|71X0ea&H]9Dsk!`kxBXlG;q$mLfv_vtaHK_rHFKu]4'<*LWCyUe@ZcI6"*wB5M@[m<Ok5/cC^=
 CxDhg=TJi^o[E
Mime-Version: 1.0 (generated by tm-edit 7.72)
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
From: =?ISO-8859-1?Q?Fran=E7ois_Pinard?= <pinard@progiciels-bpi.ca>
Date: 30 Sep 1996 13:43:26 -0400
Message-Id: <oqafu7vqyp.fsf@icule.progiciels-bpi.ca>
Sender: owner-tar-forum@IRO.UMontreal.CA
Precedence: bulk
Reply-To: tar-forum@IRO.UMontreal.CA
Xref: creche.cygnus.com mail.cpio:14
Lines: 52
X-Gnus-Newsgroup: mail.cpio:14   Sun Apr 13 23:57:47 1997

Hi, gang.  Especially Jim and Tom for this message.  Copy to tar-forum.

I'm trying to revise all accumulated mail about how, if and when to change
attributes of symbolic links, because GNU tar (a little like file utilities
and cpio) has problems in this area.

The problem is not simple.  To start with, it seems that there is quite
a variance between systems.  Besides, for a single system, behaviour
for attributes of symbolic links changed over time, so when people say
that "such system" does it this way, the statement might not always be
dependable, despite probably true at some particular point.  Also, to make
things worse, some systems even have non-uniform processing depending
on filesystems: in Linux for example, rules for proc filesystems are
different then rules for ext2 filesystems, at the same particular time.

Taken all at once, the least I can say at first is that this is fairly
confusing.  What does not help me is that some users speak with a lot
of authority, or are very or quite pushy about stating the universality
of what they think the truth is.  I was mislead more than once by some
users about various things, and not only about GNU tar, so I'm trying
more and more to ask for checkable references, before doing any deep move.
It seems that pushy users often do not have much to offer, when it comes to
portability, besides their sole conviction.  It too often shakens my own!

Benchmarking `chmod' over symlinks at configure time might only be an
half-acceptable solution, because it would just not be dependable in a
cross-compilation environment.  Benchmarking `chown' at configure time
does not make much sense when one is not root, and in GNU so far, people
can always configure and make as any user, and install as root (a small
exception exists in sh-utils).  One can still detect lchown and lchmod at
configure time even in cross-compilation environment, and deduce something
for their presence.  We cannot safely deduce much from their absence.

The only solution left to me, as far as I can see, is to benchmark chmod
and chown for symbolic links at tar execution time, and let tar learn
dynamically from these benchmarks.  This is unusual in GNU (besides
Autoconf of course, and now, a bit in GNU shar generated archives), but
this might become a working solution here.  I have no idea about the number
of pretest releases which will be needed to get the learning behaviour
right in GNU tar, either as root or as non-root -- which are different.
I have no real hope to do it correctly on the first try.  Whatever the
solution happens to be, maybe cpio might adopt it kind of easily, while
I suspect it might be less easy to swallow for file utilities.  Sigh!

So, before diving into all this (and I have only a few hours weekly for
GNU tar), I wanted to know if other Gnits maintainers have some opinion
or conviction about all this, or sounded advice to offer to me...

-- 
Frangois Pinard         ``Vivement GNU!''        pinard@iro.umontreal.ca
Support Programming Freedom, join our League!  Ask lpf@lpf.org for info!


From pinard@progiciels-bpi.ca Sun May 17 23:50:35 1998
X-From-Line: nobody Thu Oct 31 14:33:29 1996
Received: by drip.colorado.edu (cu.generic.890828)
Received: from rtsq.grics.qc.ca by geech.gnu.ai.mit.edu (8.6.12/8.6.12GNU) with ESMTP id GAA25304 for <gnits@gnu.ai.mit.edu>; Thu, 31 Oct 1996 06:47:50 -0500
Received: by rtsq.grics.qc.ca (8.7.5/8.7.3) with UUCP id GAA04749 for gnits@gnu.ai.mit.edu; Thu, 31 Oct 1996 06:49:06 -0500
X-Authentication-Warning: rtsq.grics.qc.ca: uicule set sender to pinard@icule.progiciels-bpi.ca using -f
Received: by icule.progiciels-bpi.ca (8.7.5/8.7.3) id GAA00392; 1996-10-31 06:45:23-05:00
Sender: pinard@progiciels-bpi.ca
To: GNU nit pickers club <gnits@gnu.ai.mit.edu>
Subject: All about the safe-stat issue? :-)
Reply-To: pinard@iro.umontreal.ca
X-Face: "b_m|CE6#'Q8fliQrwHl9K,]PA_o'*S~Dva{~b1n*)K*A(BIwQW.:LY?t4~xhYka_.LV?Qq
 `}X|71X0ea&H]9Dsk!`kxBXlG;q$mLfv_vtaHK_rHFKu]4'<*LWCyUe@ZcI6"*wB5M@[m<Ok5/cC^=
 CxDhg=TJi^o[E
Mime-Version: 1.0 (generated by tm-edit 7.90)
Content-Type: multipart/mixed;
 boundary="Multipart_Thu_Oct_31_06:45:16_1996-1"
From: =?ISO-8859-1?Q?Fran=E7ois_Pinard?= <pinard@progiciels-bpi.ca>
Date: 31 Oct 1996 06:45:17 -0500
Message-Id: <oq683rs6gi.fsf@icule.progiciels-bpi.ca>
Status: RO
Xref: creche.cygnus.com mail.cpio:15
Lines: 340
X-Gnus-Newsgroup: mail.cpio:15   Sun Apr 13 23:58:44 1997

--Multipart_Thu_Oct_31_06:45:16_1996-1
Content-Type: text/plain; charset=US-ASCII

Hi, people.

Here is all I have about the safe-stat issue, as something you might want
to review a last time before it disappears forever, out of your life! :-).
In fact, libit is now dropping safe-stat and safe-lstat, unless someone
has a serious objection to it.  I did not myself gave a serious thought
to the matter, and just followed Jim blindly on it (well! I confess some
reluctance, as timidly shown in the second message below :-).

Jim, I noticed you still use safe-read and full-write in your very recent
*utils.  This leaves me a bit uncomfortable: if safe-stat, safe-lstat,
safe-read and full-write were all created to solve a common problem,
I miss why some stay and some disappear.  We might also have to settle
all together on a few good ways (or the best way :-) to use SA_RESTART,
and do it for real.  Jim offers some code in the message of 1995-04-26.
Surely many packages, and at least some mine, are to be affected.  Hmph!



--Multipart_Thu_Oct_31_06:45:16_1996-1
Content-Type: message/rfc822

Date: Thu Oct 31 06:25:04 1996
From: Various
Subject: Digested Articles
MIME-Version: 1.0

Topics:
   Re: m4-prerelease
   Re: sh-utils 1.10q
   More safe_ syscall candidates...
   Re: Greg McGary: More safe_ syscall candidates...
   Re: Greg McGary: More safe_ syscall candidates...
   Re: Greg McGary: More safe_ syscall candidates...
   Re: fileutils-3.13 and lib/mkdir.c


----------------------------------------------------------------------

Date: 1994-07-18 13:39:26-05:00
From: meyering@idefix.comco.com
To: pinard@IRO.UMontreal.CA
Subject: Re: m4-prerelease
Message-Id: <9407181839.AA21106@idefix>

In case you have a lot of time on your hands, check out the ChangeLog
for GNU make re the new function called safe_stat.  I'm going to replace
all occurrences of `stat' and `lstat' in the utils with safer versions
of those functions.  This is necessary for systems (Solaris, Irix-5.2,
and maybe Linux and the Hurd) on which an interrupted stat system call
can return non-zero and set errno = EINTR.

Along the same lines, I wrote safe_read and full_write for use in the
*utils.  Maybe some of your utilities should use these functions, too?
The files are safe-read.c and full-write.c in (at least) fileutils/lib.

------------------------------

Date: 1994-10-08 20:42:25-05:00 (CDT)
From: meyering@comco.com
To: pinard@IRO.UMontreal.CA
Subject: Re: sh-utils 1.10q
Message-Id: <199410090142.UAA25406@idefix.comco.com>

| I did not take the time to look at safe-l?stat.* things yet, but
| it is hardly believable this cannot be achieved by simpler means.

Don't bet your house on it -- at least not before looking at the
code and considering the goals:

    - minimal changes to existing source (hence they have to have
	function-like syntax and take the same arguments as l?stat)

    - minimal impact on efficiency -- even on systems for which
	there is relatively high function call overhead.  That's
	why the macros resolve to statement expression macros when
	compiling with gcc.

    - *no* impact on efficiency for systems that don't define EINTR
	[but this isn't that important]

| I wish I would have more time to prove this intuition of mine.

If you find a better way, I'll be a bit chagrined... :-)
But don't let that stop you from trying!   Hmmm...  Maybe (quite
the contrary) my having said that will spur you on to even greater
lengths in search of a simpler solution :-)

BTW, what do you find complicated about the safe-[lx]?stat.* files?
Perhaps it's the make rules you'd rather avoid?  Well, as I suggested,
to use this l?stat interface you could skip the safe-x?stat.cin files
(and the four make rules to build *.[ch] from them) and simply include
the four files (safe-l?stat.[ch]) in your distributions.

------------------------------

Date: 1995-04-09 17:10-04:00
From: Greg McGary <gkm@magilla.cichlid.com>
To: meyering@comco.com
CC: pinard@IRO.UMontreal.CA
Subject: More safe_ syscall candidates...
Message-Id: <m0ry4Fc-0004goC@magilla.magilla.cichlid.com>

It occurred to me that if you need safe versions of {,l}stat, you
ought to need safe versions for all other syscalls that take file name
arguments, since it's during the potentially long-running call to
namei that these would fail with EINTR.

These spring to mind:

	access
	chdir
	chmod
	chown
	chroot
	exec*
	link
	mount
	open
	readlink
	rename
	statfs
	symlink
	truncate
	umount
	utime
	(any more?)

Eek!


------------------------------

Date: 1995-04-26 09:26:19-05:00
From: Jim Meyering <meyering@comco.com>
To: Roland McGrath <roland@gnu.ai.mit.edu>
cc: gkm@magilla.cichlid.com, pinard@IRO.UMontreal.CA,
        drepper@ipd.info.uni-karlsruhe.de (Ulrich Drepper),
        djm@uunet.uu.net (David J. MacKenzie)
Subject: Re: Greg McGary: More safe_ syscall candidates...
Message-Id: <199504261426.JAA29703@idefix.comco.com>

On Wed, 12 Apr 1995 17:41:49 -0400, Roland McGrath wrote:
| This is really a ridiculous lossage of Solaris.  Someone convinced me to do
| the safe_stat kludge in Make, but I am loathe to hair things up all over
| the place [by handling EINTR returns from all syscalls that deal with the
| file system].
|
| Let's review: the problem is that filesystem calls blocked on slow NFS
| can return EINTR when you interrupt Make?

I didn't know that was the impetus for the change.

| Isn't Solaris supposed to be POSIX.1-conformant?

I think so.  But I don't use Solaris much.
This also affects (SGI's) Irix-[56] -- pretty SYSVr4-ish,
but not Irix-4.

| Can't we just use SA_RESTART?

Hmm...  That looks like it will do the trick, at least on Irix
systems.  Irix-4 syscalls don't return EINTR and <signal.h> doesn't
define SA_RESTART, so that's not a problem, either.  Then all we
need is to test #if HAVE_SIGACTION && defined (SA_RESTART) to decide
whether to add SA_RESTART to sigactions.  Then, every utility should
make sure that the sigactions with handlers that return normally have
that flag bit set.

All that makes me think that my safe_stat changes were for nought.
But that's ok.

I guess that means that every utility that uses any syscall that
may return EINTR should use sigaction to prevent that.  What signals
besides TSTP?  STOP? TTOU, WINCH, HUP...  It seems like overkill
to call sigaction twice for every valid signal, but here's my first
crack at the function:

#include <signal.h>
#include <stdlib.h>

#define HAVE_SIGACTION 1

void
sig_restart_syscalls ()
{
#if HAVE_SIGACTION && defined (SA_RESTART)
  int i;
  for (i = 1; i < NSIG; i++)
    {
      struct sigaction act;
      if (sigaction (i, NULL, &act))
	continue;
      act.sa_flags |= SA_RESTART;
      sigaction (i, &act, NULL);
    }
#endif
}


------------------------------

Date: 1995-05-05 09:02:15-05:00
From: Jim Meyering <meyering@comco.com>
To: Roland McGrath <roland@gnu.ai.mit.edu>
cc: gkm@magilla.cichlid.com, pinard@IRO.UMontreal.CA,
        drepper@ipd.info.uni-karlsruhe.de, djm@uunet.uu.net,
        gnu-prog-disc@gnu.ai.mit.edu
Subject: Re: Greg McGary: More safe_ syscall candidates...
Message-Id: <199505051402.JAA12047@idefix.comco.com>

[This is the end (I hope) of our discussion on whether wrappers
 like safe_stat are useful.  I conclude they're not.  Thanks to Greg
 for prompting this investigation.  ]

I ran some experiments (on SGIs) in an attempt to make stat(2) fail
with errno == EINTR, then posted to a couple of comp.sys.sgi.*
newsgroups asking them about it.  The two replies (both from SGI
employees) confirmed that (on SGIs at least) EINTR is returned only
when you attempt to access a file on a hung NFS-mounted file system,
a sufficiently long interval elapses with no change, and an interrupt
is handled by a handler that doesn't exit.  If anyone knows of other
circumstances in which this can happen (esp, in the Hurd), please let
me know.  This isn't an SGI-specific issue.

So, I'm going to remove safe_stat from of all the packages I maintain
because all of those programs exit from any signal handlers.

If you maintain a program that doesn't exit after catching a
signal, I suggest you read about sigaction and SA_RESTART in the
GNU C Library manual or sigaction(2) on a system that supports it.
You should consider setting the SA_RESTART bit in action.sa_flags
for every such signal handler.

My goal was to have stat et. al. act just as they normally would.
I didn't want stat's EINTR-failure to cause spurious program failure.
Of course, if you want to handle specially the errno == EINTR case,
you shouldn't use SA_RESTART.

--
Jim

FYI, here's the posting:

  From meyering Wed Apr 26 16:33:16 CDT 1995
  Newsgroups: comp.sys.sgi.admin,comp.sys.sgi.misc
  Subject: Irix5: how to make stat(2) et. al. fail with errno == EINTR
  Organization: Computational Mechanics Co. Inc.

  I would like to know how to make stat(2) (and all of the other system
  calls that deal with the file system) fail and set errno to EINTR.
  >From  the Irix-5.3 stat(2) man page:

       EINTR     A signal was caught during the stat or lstat system call.

  But even when I run a test program that repeatedly stat's a 400-component
  file name (I tried files both local and on NFS mounts) and bombard
  it with SIGINTs, stat still always succeeds.  Of course, I've also
  set up a handler for the interrupt signal.  I'm using Irix-5.3.

  The ultimate goal of this experiment is more robust code.
  I want to be able to ensure that e.g. stat does *not* ever return
  EINTR, but instead just resumes the system call (see the discussion
  of SA_RESTART in sigaction(2)).  The alternative is to write code to
  detect and handle the case in which any of the (at least) 20 affected
  syscalls fails and sets errno to EINTR.  That's gross.

  Any suggestions?


------------------------------

Date: 1995-05-05 10:20:13-04:00
From: Michael I Bushnell <mib@gnu.ai.mit.edu>
To: meyering@comco.com
CC: roland@gnu.ai.mit.edu, gkm@magilla.cichlid.com, pinard@IRO.UMontreal.CA,
        drepper@ipd.info.uni-karlsruhe.de, djm@uunet.uu.net,
        gnu-prog-disc@gnu.ai.mit.edu
Subject: Re: Greg McGary: More safe_ syscall candidates...
Message-Id: <199505051420.KAA06992@duality.gnu.ai.mit.edu>

EINTR can happen more broadly in the Hurd, including stat.

(Remember, of course, that EINTR can only happen in a program which
has a signal handler which returns normally [not via longjmp].)

   If you maintain a program that doesn't exit after catching a
   signal, I suggest you read about sigaction and SA_RESTART in the
   GNU C Library manual or sigaction(2) on a system that supports it.
   You should consider setting the SA_RESTART bit in action.sa_flags
   for every such signal handler.

Yes, that works correctly in the Hurd (modulo bugs).

Another plea: if your program blocks SIGINT, don't block it across
calls to chdir, stat, etc.  On Real Systems those calls are
interruptible and users will be annoyed if C-c doesn't work.

Bash is a notable culprit here.  Chet?

Michael




------------------------------

Date: 1996-09-28 13:29:16-05:00
From: Jim Meyering <meyering@asic.sc.ti.com>
To: pinard@IRO.UMontreal.CA, pinard@progiciels-bpi.ca
Subject: Re: fileutils-3.13 and lib/mkdir.c
Message-Id: <199609281829.NAA01484@appaloosa.asic.sc.ti.com>
References: <199607141533.LAA04080@localhost.iro.umontreal.ca>

| OK...  You are going away of safe-stat, I think?  I do not remember why you
| went nearer (and us all with you ;-), and then further.  I surely have some
| information saved somewhere about it, but being lazy on this sunny Sunday,
| maybe you'll accept telling me in a few words.
| 
Don't use safe-stat junk.  I don't feel like digging up the reason right
not [...]

------------------------------

End of forwarda00122 Digest
***************************

--Multipart_Thu_Oct_31_06:45:16_1996-1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Fran=E7ois Pinard         ``Vivement GNU!''        pinard@iro.umontreal.c=
a
Support Programming Freedom, join our League!  Ask lpf@lpf.org for info!

--Multipart_Thu_Oct_31_06:45:16_1996-1--


From pinard@progiciels-bpi.ca Sun May 17 23:50:35 1998
X-From-Line: nobody Wed Nov  6 10:54:03 1996
Received: by drip.colorado.edu (cu.generic.890828)
Received: from degusse.iro.umontreal.ca (degusse.IRO.UMontreal.CA [132.204.32.45]) by cygnus.com (8.6.12/8.6.9) with ESMTP id JAA07622; Wed, 6 Nov 1996 09:40:47 -0800
Received: (from daemon@localhost) by degusse.iro.umontreal.ca (8.7.5/8.7.3) id MAA02954 for tar-forum-outgoing; Wed, 6 Nov 1996 12:39:59 -0500 (EST)
Received: from rtsq.grics.qc.ca (root@rtsq.grics.qc.ca [199.84.132.10]) by degusse.iro.umontreal.ca (8.7.5/8.7.3) with ESMTP id MAA02939 for <tar-forum@iro.umontreal.ca>; Wed, 6 Nov 1996 12:39:46 -0500 (EST)
Received: by rtsq.grics.qc.ca (8.7.5/8.7.3) with UUCP id NAA19181; Wed, 6 Nov 1996 13:36:14 -0500
X-Authentication-Warning: rtsq.grics.qc.ca: uicule set sender to pinard@icule.progiciels-bpi.ca using -f
Received: by icule.progiciels-bpi.ca (8.7.5/8.7.3) id MAA00894; 1996-11-06 12:11:30-05:00
To: Nat Makarevitch <nat@nataa.fr.eu.org>
Cc: Forum of GNU tar pretesters <tar-forum@IRO.UMontreal.CA>
Subject: Re: tar 1.11.8 bug with '*/' file filter
References: <m23ez5wfi3.fsf@nataa.fr.eu.org>
X-Face: "b_m|CE6#'Q8fliQrwHl9K,]PA_o'*S~Dva{~b1n*)K*A(BIwQW.:LY?t4~xhYka_.LV?Qq
 `}X|71X0ea&H]9Dsk!`kxBXlG;q$mLfv_vtaHK_rHFKu]4'<*LWCyUe@ZcI6"*wB5M@[m<Ok5/cC^=
 CxDhg=TJi^o[E
Mime-Version: 1.0 (generated by tm-edit 7.90)
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
From: pinard@progiciels-bpi.ca (=?ISO-8859-1?Q?Fran=E7ois?= Pinard)
Date: 06 Nov 1996 12:11:25 -0500
In-Reply-To: Nat Makarevitch's message of 1996-10-23 23:13:40+02:00
Message-Id: <oqzq0v6tdu.fsf@icule.progiciels-bpi.ca>
X-Mailer: Red Gnus v0.53/Emacs 19.34
Sender: owner-tar-forum@IRO.UMontreal.CA
Precedence: bulk
Reply-To: tar-forum@IRO.UMontreal.CA
Xref: creche.cygnus.com mail.cpio:16
Lines: 55
X-Gnus-Newsgroup: mail.cpio:16   Sun Apr 13 23:59:11 1997

Nat Makarevitch <nat@nataa.fr.eu.org> writes:

| using tar 1.11.8 under Linux, I think that the result of a tar command
| implying a filename filter "*/" is not adequate.  Example : "tar tvf
| tarfile_name '*/'" is now buggy because it seems to me that it must
| show only the directories contained. it eventually shows the whole
| content of the archive.

The matching done over tar arguments uses the same routine as the --exclude
option, which documentation follows below; just replace "exclude" by
"include" in the last sentence.  It appears to me that tar behaves as
documented.  I do not see on which reference you base words like "not
adequate", "now buggy" or "must".

Maybe you just do not like how GNU tar behaves, and you would like this
to change.  At this time, I have no strong opinion about what would be best
for interpreting the syntax.  One thing is that a change of semantics is
a delicate thing to impose on GNU tar users, without good reasons for it.

I'm also forwarding this reply to a group of interested tar users, who
have been good advisors for me in the past.

======================================================================>
   A PATTERN should be written according to shell syntax, using
wildcard characters to effect globbing.  Most characters in the pattern
stand for themselves in a file name, and case is significant: `a' will
match only `a', and not `A'.  The character `?' in the pattern matches
any single character in the file name.  The character `*' in the
pattern matches zero, one or more single characters in the file name.
The character `[', up to the matching `]', introduces a character class,
and is described in the next paragraph.  The character `\' in a pattern
merely introduces the following character of the pattern as matching a
single character in the file name; it is useful when one needs to match
`?', `*', `[' or `\' themselves.

   A character class is a list of acceptable characters for the next
single character of the file name.  However, if the first character of
the class, just after the opening `[', is `!' or `^', then the meaning
of the class is reversed, and it rather lists those characters which
are *forbidden* as the next single character of the file name.  Other
characters of the class stand for themselves.  The special construction
`L-M', using an hyphen between two letters, is meant to represent all
characters between L and M included.

   Periods (`.') or slashes (`/') are not considered special for
wildcard matches.  However, if a pattern completely matches a directory
prefix of a file name, then it matches the full file name: that is to
say that that excluding a directory also excludes all the files beneath
it.
======================================================================<

-- 
Frangois Pinard         ``Vivement GNU!''        pinard@iro.umontreal.ca
Support Programming Freedom, join our League!  Ask lpf@lpf.org for info!


From pinard@progiciels-bpi.ca Sun May 17 23:50:35 1998
X-From-Line: nobody Sun Nov 10 09:39:14 1996
Received: by drip.colorado.edu (cu.generic.890828)
Received: from degusse.iro.umontreal.ca (degusse.IRO.UMontreal.CA [132.204.32.45]) by cygnus.com (8.6.12/8.6.9) with ESMTP id HAA15375; Sat, 9 Nov 1996 07:39:06 -0800
Received: (from daemon@localhost) by degusse.iro.umontreal.ca (8.7.5/8.7.3) id KAA00758 for tar-forum-outgoing; Sat, 9 Nov 1996 10:38:38 -0500 (EST)
Received: from rtsq.grics.qc.ca (root@rtsq.grics.qc.ca [199.84.132.10]) by degusse.iro.umontreal.ca (8.7.5/8.7.3) with ESMTP id KAA00744 for <tar-forum@iro.umontreal.ca>; Sat, 9 Nov 1996 10:38:23 -0500 (EST)
Received: by rtsq.grics.qc.ca (8.7.5/8.7.3) with UUCP id LAA06523 for tar-forum@iro.umontreal.ca; Sat, 9 Nov 1996 11:36:33 -0500
X-Authentication-Warning: rtsq.grics.qc.ca: uicule set sender to pinard@icule.progiciels-bpi.ca using -f
Received: by icule.progiciels-bpi.ca (8.7.5/8.7.3) id KAA04281; 1996-11-09 10:34:31-05:00
To: Forum of GNU tar pretesters <tar-forum@IRO.UMontreal.CA>
Subject: Re: tar 1.11.8 bug with '*/' file filter
X-Face: "b_m|CE6#'Q8fliQrwHl9K,]PA_o'*S~Dva{~b1n*)K*A(BIwQW.:LY?t4~xhYka_.LV?Qq
 `}X|71X0ea&H]9Dsk!`kxBXlG;q$mLfv_vtaHK_rHFKu]4'<*LWCyUe@ZcI6"*wB5M@[m<Ok5/cC^=
 CxDhg=TJi^o[E
Mime-Version: 1.0 (generated by tm-edit 7.90)
Content-Type: multipart/mixed;
 boundary="Multipart_Sat_Nov__9_10:34:25_1996-1"
Content-Transfer-Encoding: 7bit
From: pinard@progiciels-bpi.ca (=?ISO-8859-1?Q?Fran=E7ois?= Pinard)
Date: 09 Nov 1996 10:34:28 -0500
Message-Id: <oq683fjn97.fsf@icule.progiciels-bpi.ca>
X-Mailer: Red Gnus v0.55/Emacs 19.34
Sender: owner-tar-forum@IRO.UMontreal.CA
Precedence: bulk
Reply-To: tar-forum@IRO.UMontreal.CA
Xref: creche.cygnus.com mail.cpio:17
Lines: 116
X-Gnus-Newsgroup: mail.cpio:17   Sun Apr 13 23:59:17 1997

--Multipart_Sat_Nov__9_10:34:25_1996-1
Content-Type: text/plain; charset=US-ASCII

Hi, people.  For your information and possible reactions.


--Multipart_Sat_Nov__9_10:34:25_1996-1
Content-Type: message/rfc822

To: pinard@IRO.UMontreal.CA
Subject: Re: tar 1.11.8 bug with '*/' file filter
References: <m23ez5wfi3.fsf@nataa.fr.eu.org>
	<oqzq0v6tdu.fsf@icule.progiciels-bpi.ca>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
From: Nat Makarevitch <nat@nataa.fr.eu.org>
Date: 1996-11-09 13:11:26+01:00
Message-ID: <m2ohh74gep.fsf@nataa.fr.eu.org>

F. Pinard writes:

>> using tar 1.11.8 under Linux, I think that the result of a tar command
>> implying a filename filter "*/" is not adequate.  Example : "tar tvf
>> tarfile_name '*/'" is now buggy because it seems to me that it must show
>> only the directories contained. it eventually shows the whole content of
>> the archive.

> The matching done over tar arguments uses the same routine as the
> --exclude option, which documentation follows below;

> I do not see on which reference you base words like "not adequate", "now
> buggy" or "must".

I beg your pardon, I did not want to be offensive nor rude. I am very
grateful or the wonderful job done.

"not adequate":
because I can not determine how I can filter only directories in an archive
not why it may be considered as improper.

"now buggy": because previous versions of tar worked the way I was used to
(at least since '92)

"must" because I think that the behaviour of the old version is more
conform to the dox than the behaviour of new one.

example (excerpt from a simulated work session):
-=-=-=-=
% tar.old --version
GNU tar version 1.11.2
% tar --version
GNU tar 1.11.8
% pwd
~/tmp/t
% ls -F
dir1/   dir2/   file_1  file_2  file_3
% tar cvf toto.tar *
dir1/
dir2/
file_1
file_2
file_3
% tar tvf toto.tar '*/'
drwxr-x--- nat/root          0 Nov  9 12:44 1996 dir1/
drwxr-x--- nat/root          0 Nov  9 12:45 1996 dir2/
-rw-r----- nat/root      44053 Nov  9 12:44 1996 file_1
-rw-r----- nat/root        371 Nov  9 12:44 1996 file_2
-rw-r----- nat/root        655 Nov  9 12:44 1996 file_3
% tar.old tvf toto.tar '*/'
drwxr-x--- nat/root          0 Nov  9 12:44 1996 dir1/
drwxr-x--- nat/root          0 Nov  9 12:45 1996 dir2/
=-=-=-=-

I understand that:
-=-=-=- snippet of the "tar" documentation
Periods (`.') or slashes (`/') are not considered special for wildcard
matches.  However, if a pattern completely matches a directory prefix of a
file name, then it matches the full file name: that is to say that that
excluding a directory also excludes all the files beneath it.
=-=-=-=
may imply that the implicit period of the root directory of the archive
will cause a match ("./") but I am affraid that this may be
counterintuitive and not very useful.

> Maybe you just do not like how GNU tar behaves, and you would like this
> to change.

perhaps is this evolution a non-planned side effect (?)

> One thing is that a change of semantics is a delicate thing to impose on
> GNU tar users, without good reasons for it.

I agree wholeheartly. the new behaviour is a change, and I am astounished
:-))

> I'm also forwarding this reply to a group of interested tar users, who
> have been good advisors for me in the past.

I honoured your "Reply-To" field. please fwd this mail it to whoever may be
interested, treat it just as if it was your property.

thank you for your kind interest and appreciated job

-- 
Nat    Linux


--Multipart_Sat_Nov__9_10:34:25_1996-1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

Frangois Pinard         ``Vivement GNU!''        pinard@iro.umontreal.ca
Support Programming Freedom, join our League!  Ask lpf@lpf.org for info!
--Multipart_Sat_Nov__9_10:34:25_1996-1--



From pinard@progiciels-bpi.ca Sun May 17 23:50:35 1998
X-From-Line: nobody Sun Nov 10 09:39:14 1996
Received: by drip.colorado.edu (cu.generic.890828)
Received: from degusse.iro.umontreal.ca (degusse.IRO.UMontreal.CA [132.204.32.45]) by cygnus.com (8.6.12/8.6.9) with ESMTP id HAA15378; Sat, 9 Nov 1996 07:39:10 -0800
Received: (from daemon@localhost) by degusse.iro.umontreal.ca (8.7.5/8.7.3) id KAA00780 for tar-forum-outgoing; Sat, 9 Nov 1996 10:38:59 -0500 (EST)
Received: from rtsq.grics.qc.ca (root@rtsq.grics.qc.ca [199.84.132.10]) by degusse.iro.umontreal.ca (8.7.5/8.7.3) with ESMTP id KAA00759 for <tar-forum@iro.umontreal.ca>; Sat, 9 Nov 1996 10:38:43 -0500 (EST)
Received: by rtsq.grics.qc.ca (8.7.5/8.7.3) with UUCP id LAA06554; Sat, 9 Nov 1996 11:39:33 -0500
X-Authentication-Warning: rtsq.grics.qc.ca: uicule set sender to pinard@icule.progiciels-bpi.ca using -f
Received: by icule.progiciels-bpi.ca (8.7.5/8.7.3) id KAA04299; 1996-11-09 10:37:27-05:00
To: Nat Makarevitch <nat@nataa.fr.eu.org>
Cc: Forum of GNU tar pretesters <tar-forum@IRO.UMontreal.CA>
Subject: Re: tar 1.11.8 bug with '*/' file filter
References: <m23ez5wfi3.fsf@nataa.fr.eu.org> 	<oqzq0v6tdu.fsf@icule.progiciels-bpi.ca> <m2ohh74gep.fsf@nataa.fr.eu.org>
X-Face: "b_m|CE6#'Q8fliQrwHl9K,]PA_o'*S~Dva{~b1n*)K*A(BIwQW.:LY?t4~xhYka_.LV?Qq
 `}X|71X0ea&H]9Dsk!`kxBXlG;q$mLfv_vtaHK_rHFKu]4'<*LWCyUe@ZcI6"*wB5M@[m<Ok5/cC^=
 CxDhg=TJi^o[E
Mime-Version: 1.0 (generated by tm-edit 7.90)
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
From: pinard@progiciels-bpi.ca (=?ISO-8859-1?Q?Fran=E7ois?= Pinard)
Date: 09 Nov 1996 10:37:20 -0500
In-Reply-To: Nat Makarevitch's message of 1996-11-09 13:11:26+01:00
Message-Id: <oq4tizjn4f.fsf@icule.progiciels-bpi.ca>
X-Mailer: Red Gnus v0.55/Emacs 19.34
Sender: owner-tar-forum@IRO.UMontreal.CA
Precedence: bulk
Reply-To: tar-forum@IRO.UMontreal.CA
Xref: creche.cygnus.com mail.cpio:18
Lines: 48
X-Gnus-Newsgroup: mail.cpio:18   Sun Apr 13 23:59:19 1997

Nat Makarevitch <nat@nataa.fr.eu.org> writes:

| > I do not see on which reference you base words like "not adequate",
| > "now buggy" or "must".
| 
| I beg your pardon, I did not want to be offensive nor rude. I am very
| grateful or the wonderful job done.

I did not read your message as offensive.  I was only bothered by the
lack of references, which I need.

| "not adequate": because [...]
| "now buggy": because [...]
| "must" because [...]

I'm filing your report.  Let me write to you again when the time comes
for me to work on this problem.  My work queue is lengthy, it may take
a good while.  But I'm not forgetting you.  Thanks for caring!

| > Maybe you just do not like how GNU tar behaves, and you would like this
| > to change.
| perhaps is this evolution a non-planned side effect (?)

Maybe!  Since I taken over the maintenance of tar, I'm slowly learning it
as I process accumulated or new bug reports.  There are many tar features
which I never used before and am unfamiliar with, so it is possible that
I implement changes inadvertently, even paying a lot of attention not to.

But I do not think or remember having changed things in the area of exclude
recognition, and it will require some doing before I can study seriously
the problems you report, that's why I'm delaying this work for some day
I'll have more free time, or process other --exclude related problems.

| > I'm also forwarding this reply to a group of interested tar users, who
| > have been good advisors for me in the past.
| 
| I honoured your "Reply-To" field. please fwd this mail it to whoever may be
| interested, treat it just as if it was your property.

The Reply-To is automatically generated, because the From is not my
preferred address.  I forwarded your message to tar-forum.  Thanks.

-- The maintainer

-- 
Frangois Pinard         ``Vivement GNU!''        pinard@iro.umontreal.ca
Support Programming Freedom, join our League!  Ask lpf@lpf.org for info!


From pinard@progiciels-bpi.ca Sun May 17 23:50:35 1998
X-From-Line: nobody Wed Nov  6 10:54:03 1996
Received: by drip.colorado.edu (cu.generic.890828)
Received: from degusse.iro.umontreal.ca (degusse.IRO.UMontreal.CA [132.204.32.45]) by cygnus.com (8.6.12/8.6.9) with ESMTP id JAA07899; Wed, 6 Nov 1996 09:43:48 -0800
Received: (from daemon@localhost) by degusse.iro.umontreal.ca (8.7.5/8.7.3) id MAA02999 for tar-forum-outgoing; Wed, 6 Nov 1996 12:43:35 -0500 (EST)
Received: from rtsq.grics.qc.ca (bnjpdl@rtsq.grics.qc.ca [199.84.132.10]) by degusse.iro.umontreal.ca (8.7.5/8.7.3) with ESMTP id MAA02986 for <tar-forum@iro.umontreal.ca>; Wed, 6 Nov 1996 12:43:24 -0500 (EST)
Received: by rtsq.grics.qc.ca (8.7.5/8.7.3) with UUCP id NAA19413; Wed, 6 Nov 1996 13:43:00 -0500
X-Authentication-Warning: rtsq.grics.qc.ca: bin set sender to pinard@icule.progiciels-bpi.ca using -f
Received: by icule.progiciels-bpi.ca (8.7.5/8.7.3) id MAA01013; 1996-11-06 12:41:44-05:00
To: kwzh@gnu.ai.mit.edu (Karl Heuer)
Cc: Qobi@uvm-gen.emba.uvm.edu, system-hackers@ai.mit.edu,
        Forum of GNU tar pretesters <tar-forum@IRO.UMontreal.CA>
Subject: Re: source code for GNU tar
References: <9610251729.AA22438@kelp.boston.ma.us>
X-Face: "b_m|CE6#'Q8fliQrwHl9K,]PA_o'*S~Dva{~b1n*)K*A(BIwQW.:LY?t4~xhYka_.LV?Qq
 `}X|71X0ea&H]9Dsk!`kxBXlG;q$mLfv_vtaHK_rHFKu]4'<*LWCyUe@ZcI6"*wB5M@[m<Ok5/cC^=
 CxDhg=TJi^o[E
Mime-Version: 1.0 (generated by tm-edit 7.90)
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
From: pinard@progiciels-bpi.ca (=?ISO-8859-1?Q?Fran=E7ois?= Pinard)
Date: 06 Nov 1996 12:41:40 -0500
In-Reply-To: kwzh@gnu.ai.mit.edu's message of 1996-10-25 13:29:24-04:00
Message-Id: <oqybgf6rzf.fsf@icule.progiciels-bpi.ca>
X-Mailer: Red Gnus v0.53/Emacs 19.34
Sender: owner-tar-forum@IRO.UMontreal.CA
Precedence: bulk
Reply-To: tar-forum@IRO.UMontreal.CA
Xref: creche.cygnus.com mail.cpio:19
Lines: 52
X-Gnus-Newsgroup: mail.cpio:19   Sun Apr 13 23:59:44 1997

kwzh@gnu.ai.mit.edu (Karl Heuer) writes:

| qobi@uvm-gen.emba.uvm.edu writes:
|
| > [...] they screwed up.  They truncated file names to 31 characters.
| > Because I have many files that have names that share the first
| > 31 characters I have a situation where they wrote a tar tape
| > that has multiple files with the same name on it.  Using an
| > unmodified tar, the multiple copies overwrite each other and
| > I only get the last file.  So I need to modify tar to generate
| > unique names on overwrite.
| 
| If GNU tar doesn't already have an option like this, then it would
| be a good thing to add.  I've had a similar situation where I need
| to extract longname files on a shortname system -- i.e., all file
| names are truncated to 14 characters.

For a long time, Marty Leisner has been insisting so we implement a file
backup option to tar so files are renamed before overwrite, similar
to the --backup option in a few GNU file utilities, similarly obeying
SIMPLE_BACKUP_SUFFIX and VERSION_CONTROL.  His idea has been strongly
supported by different people, in various forms and ways, and maybe
implementing this would solve all problems described above.

If any existing file was backed up before being overwritten by extraction,
and this reported adequately reported while in verbose mode, then clashing
files would automatically be renamed to be unique, and the true name
kept for only the last file of a series of clashing files.

This would require users to use the --backup option to tar and most
probably set environment variables as well.  The --backup option might
also accept an optional argument, maybe?

I'm not familiar with the renaming options of pax, and Karl also have
other ideas, quoted below for reference.  My guess here is that Marty's
idea would be quite sufficient, in practice.  What do you think?

| So far it hasn't been a serious problem -- I've been using pax, and
| the renaming options have been sufficient for my needs -- but I'm sure
| I'll eventually have something more complex.  Perhaps the most flexible
| solution is to add --auto-rename=PFX to tar, and arrange so that any
| file which should be extracted but can't be written (or shouldn't be
| written because of --keep-old-files) will instead be written to the name
| generated by sprintf(name, "%s%d", PFX, n++).  (PFX would likely be a
| directory name ending in "/".)  In addition, tar should do sprintf(name,
| "%sINDEX", PFX) and use that file to log what it's doing, one line for
| each such rename.

-- 
Frangois Pinard         ``Vivement GNU!''        pinard@iro.umontreal.ca
Support Programming Freedom, join our League!  Ask lpf@lpf.org for info!


From dairiki@irving.apl.washington.edu Sun May 17 23:50:35 1998
X-From-Line: nobody Mon Nov 18 22:08:59 1996
Received: by drip.colorado.edu (cu.generic.890828)
Received: from irving.apl.washington.edu (root@irving.apl.washington.edu [128.95.97.194]) by cygnus.com (8.6.12/8.6.9) with ESMTP id TAA10522 for <tromey@cygnus.com>; Mon, 18 Nov 1996 19:16:42 -0800
Received: from irving.apl.washington.edu (dairiki@localhost [127.0.0.1]) by irving.apl.washington.edu (8.6.12/8.6.10) with ESMTP id TAA32082 for <tromey@cygnus.com>; Mon, 18 Nov 1996 19:16:33 -0800
Message-Id: <199611190316.TAA32082@irving.apl.washington.edu>
To: tromey@cygnus.com
Subject: Re: Bug in cpio-2.4.2, and other questions... 
In-Reply-To: Your message of "18 Nov 1996 13:15:29 MST."
             <m120drqhwe.fsf@creche.cygnus.com> 
Date: Mon, 18 Nov 1996 19:16:32 -0800
From: Jeff Dairiki <dairiki@irving.apl.washington.edu>
Xref: creche.cygnus.com mail.cpio:20
Lines: 105
X-Gnus-Newsgroup: mail.cpio:20   Sun Apr 13 23:59:49 1997

Hello Tom,

Nice to meet you.

In message <m120drqhwe.fsf@creche.cygnus.com>,Tom Tromey writes:
>I've occasionally wondered what to do about files changing underneath
>cpio.  I'm not sure that it is really possible to solve this problem,
>at least in the general case.

Well, there are two levels to this problem:

  1) It would be nice to generate a valid archive, and not munge
     the _other_ files in the archive, even if a particular target
     is mutating.

  2) Of course it would be nice to end up with a somehow useable copy
     of the mutated file in the archive as well.

I agree with you that #2 seems difficult or impractical to solve.
But my patch addresses a problem of class #1 -- cpio produces
a corrupt archive and screws up neighboring files in the archive
sometimes --- this should be fixed.

(During the course of the past weekend hackings, I have discovered
a second bug of similar nature which strikes when the target file
grows before it is fully copied by cpio -- extra cruft in the
input buffer isn't flushed before reading the next file in the archive,
so some of the 'extra' bytes from the growing file can be prepended
to the _next_ file in the archive...  I'll produce a patch for you
if you'd like.)

(A third, minor bug I discovered, is that if you use to --only-verify-crc
option, (maybe along with -it) to verify checksums, cpio will attempt
(and fail) to verify checksums even on archives which don't contain
checksums.)
 
>I don't have any plans to do this at present.  The current plan for
>the next release is:
>
>* configure/make cleanups required for GNU standards (this part is done)
>* internationalize using GNU gettext (this part is done)
>* beginnings of pax implementation (this is partly done)

Out of curiosity, what is pax?

>One concern is that I'd like GNU cpio and GNU tar to generate
>compatible archives.  GNU cpio already knows about tar archives; I'd
>like to extend it to understand GNU tar archives.
>
>This might put some constraints on compression efforts.

Actually, over the weekend I hacked up a compressing version of cpio
based on 2.4.2 and zlib-1.0.4.  It seems to work fairly well.
And I am fairly willing to merge my hacks in with whatever new
version you send me.

FYI, here are some highlights of my hacks:

 *  New option --compression[=<level>] (or -Z) enables compression.
    Writing compressed tar archives is not allowed, only cpio archives.
    
 *  In copy-out mode, files are individually compressed in a gzip
    compatible manner.  Only regular files are compressed.  Various
    compressed file types are recognized by magic number, and are
    not compressed again.  Also (only for larger files) if after
    a while (currently 16 kbytes) the compression ratio isn't
    very good, compression is abandoned, and the file is copied
    normally.

 * The file size as recorded in the cpio header is modified to reflect
   the the compressed file size.  (The original file size is available
   in the gzip trailer.)
 
 * The file name in the cpio header is modified as gzip would. i.e.
   under unix a '.gz' is added to the file name.  This isn't quite always
   done -- for example if a file with the new name already exists on 
   disk, the compressed file isn't renamed in the archive.  The original file
   name is stored in the gzip header.

 * An extra field (compliant with RFC1952 -- gzip file format) is added
   to the gzip header so that file can be recognized as having been
   compressed by cpio.

 * In copy-in mode, files which are recognized as having been compressed
   by cpio are uncompressed, and their original names are restored.

 * A result of all this is that compressed cpio archives are perfectly
   readable by older versions of cpio --- all the files will be extracted
   in compressed form (probably with .gz's added to their names), and
   these compressed files can be read with gzip.
    

>Unfortunately my version of cpio isn't working right now.  But once I
>fix the lingering bugs I could give you a prerelease if you want to
>play with it.  Or I could add you to the list of people who get
>notified about alpha releases, if you are interested.

Yes, please add me to your list, and I'd like to see your prerelease
when it's ready.

As already said, if you like my vision for compression in cpio,
I'd be happy to add it.

Jeff


From tromey@creche.cygnus.com Sun May 17 23:50:36 1998
X-From-Line: nobody Wed Dec 18 10:23:23 1996
Received: by drip.colorado.edu (cu.generic.890828)
Received: from creche.cygnus.com (tromey@creche.cygnus.com [192.203.188.26]) by cygnus.com (8.6.12/8.6.9) with ESMTP id JAA17182 for <tromey@cygnus.com>; Wed, 18 Dec 1996 09:15:54 -0800
Received: (from tromey@localhost) by creche.cygnus.com (8.6.12/8.6.9) id KAA18145; Wed, 18 Dec 1996 10:18:54 -0700
To: tromey@cygnus.com
Subject: [gnu.utils.bug] gnu cpio
X-Zippy:  I hope you millionaires are having fun!  I just invested half
 your life savings in yeast!!
X-Attribution:  Tom
Reply-To: tromey@cygnus.com
From: Tom Tromey <tromey@creche.cygnus.com>
Date: 18 Dec 1996 10:18:53 -0700
Message-Id: <m1afrbwz2a.fsf@creche.cygnus.com>
X-Mailer: Red Gnus v0.34/Emacs 19.34
Xref: creche.cygnus.com mail.cpio:21
Lines: 112
X-Gnus-Newsgroup: mail.cpio:21   Mon Apr 14 00:00:58 1997


Tom
-- 
tromey@cygnus.com                 Member, League for Programming Freedom

------- Start of forwarded message -------
From: abs@maunsell.co.uk (Andy Smith)
Message-ID: <199612171954.TAA25415@lonp.maunsell.co.uk>
Subject: gnu cpio
Date: Tue, 17 Dec 1996 19:54:49 +0000
Newsgroups: gnu.utils.bug

To: bug-gnu-utils@prep.ai.mit.edu
Date: Tue, 5 Nov 1996 18:28:31 +0000 (GMT)

I have been using GNU cpio successfully for many years now to do remote
tape backups from a number of workstations.  The tape server has until
now been a (number of) Intel PC's running ISC, and the clients have
been other Intel PC's running ISC and Solaris2, sun workstations
running SunOS and sun workstations running Solaris2.

I have just changed one tapeserver to a sun running Solaris2, and
encountered a problem.  The ISC and solaris clients work just fine, but
the SunOS clients give an error.  Here is a typical command and a trace
of what happens.  Has anyone else encountered this? :-

NB witg == SunOS client (4.1.3_U1)
   witf == Solaris2 server (2.4 + recommended patches)
   /usr/tmp/cpio == GNU cpio version 2.4.2 (compiled just this morning)

witg[60]> trace /usr/tmp/cpio -oHnewc -C51200 -O witf:/dev/rmt/1
open ("/usr/lib/ld.so", 0, 0222000) = 3
read (3, "".., 32) = 32
mmap (0, 40960, 0x5, 0x80000002, 3, 0) = 0xef7f3000
mmap (0xef7fb000, 8192, 0x7, 0x80000012, 3, 32768) = 0xef7fb000
open ("/dev/zero", 0, 07) = 4
getrlimit (3, 0xeffff7b0) = 0
mmap (0xef800000, 8192, 0x3, 0x80000012, 4, 0) = 0xef800000
close (3) = 0
getuid () = 10648
getgid () = 100
open ("/etc/ld.so.cache", 0, 05000100021) = 3
fstat (3, 0xeffff650) = 0
mmap (0, 4096, 0x1, 0x80000001, 3, 0) = 0xef7ef000
close (3) = 0
open ("/usr/lib/libc.so.1.9", 0, 0200200) = 3
read (3, "".., 32) = 32
mmap (0, 458764, 0x5, 0x80000002, 3, 0) = 0xef77b000
mmap (0xef7e7000, 16384, 0x7, 0x80000012, 3, 442368) = 0xef7e7000
close (3) = 0
open ("/usr/lib/libdl.so.1.0", 0, 0200220) = 3
read (3, "".., 32) = 32
mmap (0, 16396, 0x5, 0x80000002, 3, 0) = 0xef773000
mmap (0xef775000, 8192, 0x7, 0x80000012, 3, 8192) = 0xef775000
close (3) = 0
close (4) = 0
getpagesize () = 4096
brk (0x158c8) = 0
brk (0x168c8) = 0
umask (0) = 02
pipe (0x12750) = 3
pipe (0x12730) = 5
fork () = 6365
close (3) = 0
close (6) = 0
sigblock (0x1000) = 0
sigvec (13, 0xeffff544, 0xeffff538) = 0
sigvec (13, 0xeffff4cc, 0) = 0
sigsetmask (0) = 0x1000
write (4, "O/dev/rmt/1\n1537\n", 17) = 17
sigblock (0x1000) = 0
sigvec (13, 0xeffff544, 0xeffff538) = 0
sigvec (13, 0xeffff4cc, 0) = 0
sigsetmask (0) = 0x1000
read (5, "E", 1) = 1
read (5, "2", 1) = 1
read (5, "2", 1) = 1
read (5, "\n", 1) = 1
read (5, "I", 1) = 1
read (5, "n", 1) = 1
read (5, "v", 1) = 1
read (5, "a", 1) = 1
read (5, "l", 1) = 1
read (5, "i", 1) = 1
read (5, "d", 1) = 1
read (5, " ", 1) = 1
read (5, "a", 1) = 1
read (5, "r", 1) = 1
read (5, "g", 1) = 1
read (5, "u", 1) = 1
read (5, "m", 1) = 1
read (5, "e", 1) = 1
read (5, "n", 1) = 1
read (5, "t", 1) = 1
read (5, "\n", 1) = 1
write (2, "/usr/tmp/cpio: ", 15) = /usr/tmp/cpio: 15
write (2, "witf:/dev/rmt/1", 15) = witf:/dev/rmt/115
write (2, ": Invalid argument", 18) = : Invalid argument18
write (2, "\n", 1) = 
1
close (0) = 0
close (1) = 0
close (2) = 0
exit (1) = ?

-- 
  _          __         G.Maunsell & Ptnrs       Tel  : 0181-663-6565
 /_|   _/   (  _  '_//  160 Croydon Road,        Fax  : 0181-663-6723
(  |/)(/(/ __)//)/ //)  Beckenham, Kent BR3 4DE  Email: abs@maunsell.co.uk
        /               England.                 -or- abs@maunsl00.demon.co.uk
------- End of forwarded message -------


From tromey@creche.cygnus.com Sun May 17 23:50:36 1998
X-From-Line: nobody Mon Jun  9 12:55:12 1997
Received: from creche.cygnus.com (creche.cygnus.com [192.203.188.26])
	by drip.colorado.edu (8.8.5/8.8.5) with ESMTP id LAA09205
	for <tromey@drip.colorado.edu>; Mon, 9 Jun 1997 11:10:18 -0600 (MDT)
Received: (from tromey@localhost) by creche.cygnus.com (8.7.6/8.7.3) id LAA00893; Mon, 9 Jun 1997 11:12:38 -0600
To: tromey@drip.colorado.edu
Subject: [gnu.utils.bug] gnu cpio
X-Zippy:  I'm RELIGIOUS!!  I love a man with a HAIRPIECE!!
 Equip me with MISSILES!!
X-Attribution:  Tom
Reply-To: tromey@cygnus.com
From: Tom Tromey <tromey@creche.cygnus.com>
Date: 09 Jun 1997 11:12:38 -0600
Message-ID: <m1iuzn4s55.fsf@creche.cygnus.com>
X-Mailer: Red Gnus v0.34/Emacs 19.34
Status: RO
Lines: 51
Xref: creche.cygnus.com mail.cygnus:4289 mail.gnits:1894 mail.cpio:44
X-Gnus-Newsgroup: mail.cpio:44   Mon Jun  9 12:55:12 1997


Tom
-- 
tromey@cygnus.com                 Member, League for Programming Freedom

------- Start of forwarded message -------
From: farzin@blitz.net (Farzin Atefi)
Message-ID: <199706082215.AAA22800@atefi.blitz.net>
Subject: gnu cpio
Date: Mon, 9 Jun 1997 00:15:54 +0200
Newsgroups: gnu.utils.bug

Hi,
I'm having some problems with GNU cpio version 2.4.2 under Linux.

For example:
echo "usr/squid/logs/access.log\nbin/echo" | cpio -oa -H crc > arc.cpio

cpio -it doesn't show anything, but restoring the archive produces some
CRC errors. Either both files or bin/echo ONLY have a bad CRC.
It's clear that the logfile changed while being written, but
why is bin/echo corrupt? It does differ with the original.
I suspect the archive itself is ok, only restoring doesn't
work. If you want, I can send you a sample archive, but it's
about 300K gzipped.

Thanks,
Farzin

ps. I modified the original slightly, because it didn't
handle multi tape archives propperly. Don't think this has
anything to do with the bad CRC. Here is the patch anyway:

--- cpio-2.4.2/util.c.orig	Mon Jun 10 11:24:27 1996
+++ cpio-2.4.2/util.c	Mon Jun 10 11:24:52 1996
@@ -868,7 +868,7 @@
     error (2, errno, CONSOLE);
 
   old_tape_des = tape_des;
-  tape_offline (tape_des);
+/*  tape_offline (tape_des); */
   rmtclose (tape_des);
 
   /* Give message and wait for carrage return.  User should hit carrage return

-- 
Farzin Atefi
Riegelhofgasse 6, 96049 Bamberg, GERMANY
Voice/Fax: +49 951 52305
------- End of forwarded message -------


From rfg@monkeys.com Sun May 17 23:50:36 1998
X-From-Line: nobody Tue Dec 31 10:35:48 1996
Received: by drip.colorado.edu (cu.generic.890828)
Received: from eagle.ns.net (root@eagle.ns.net [204.75.146.20]) by cygnus.com (8.6.12/8.6.9) with ESMTP id JAA14020 for <tromey@cygnus.com>; Tue, 31 Dec 1996 09:25:52 -0800
Received: from coredump.monkeys.com (segfault.monkeys.com [204.119.242.200])
          by eagle.ns.net (8.8.4/8.8.4) with ESMTP
	  id JAA11019; Tue, 31 Dec 1996 09:25:22 -0800 (PST)
Received: from coredump.monkeys.com (rfg@localhost [127.0.0.1]) by coredump.monkeys.com (8.8.4/8.7.3) with ESMTP id JAA08947; Tue, 31 Dec 1996 09:24:21 -0800
To: tromey@cygnus.com
Cc: John Oleynick <juo@gnu.ai.mit.edu>, Brian Mays <brian@debian.org>
Subject: Re: cpio-2.4.2 bug; endless loop when -i on empty file (fix included) 
In-Reply-To: Your message of 30 Dec 1996 16:37:24 -0700.
             <m1g20nioy3.fsf@creche.cygnus.com> 
X-Copyright: (c) 1996 Ronald F. Guilmette; All rights reserved.
X-Tcpa-Virtual-Phone-Number: 204.119.242.200
Date: Tue, 31 Dec 1996 09:24:20 -0800
Message-Id: <8944.852053060@coredump.monkeys.com>
From: "Ronald F. Guilmette" <rfg@monkeys.com>
Xref: creche.cygnus.com mail.cpio:22
Lines: 47
X-Gnus-Newsgroup: mail.cpio:22   Mon Apr 14 00:01:13 1997


In message <m1g20nioy3.fsf@creche.cygnus.com>, you wrote:

>Ronald> I believe that I have found a rather blatant bug in the GNU
>Ronald> cpio-2.4.2 source code.
>
>Thanks for the report.  I've applied your patch to the current
>sources.

By the way, have you also picked up these other patches?  These are just
fixes for some alleged typos.  They seem right to me.  I found them via a
search of DejaNews which I did before posting my own recent patch for
GNU cpio.

According to the person who posted these additional patches, these fix a
rather serious bug which erupts when you try to restore a whole filesystem
(presumably including device files) using GNU cpio.

*** ./cpio-2.4.2/copyin.c	Wed Nov 30 14:49:06 1994
--- ./cpio-2.4.2/copyin.c	Sun Dec 29 02:11:23 1996
*************** process_copy_in ()
*** 688,692 ****
  		     the archive was created and later appeneded to). */
  		  link_res = link_to_maj_min_ino (file_hdr.c_name, 
! 				file_hdr.c_dev_maj, file_hdr.c_dev_maj,
  				file_hdr.c_ino);
  		  if (link_res == 0)
--- 688,692 ----
  		     the archive was created and later appeneded to). */
  		  link_res = link_to_maj_min_ino (file_hdr.c_name, 
! 				file_hdr.c_dev_maj, file_hdr.c_dev_min,
  				file_hdr.c_ino);
  		  if (link_res == 0)
*************** process_copy_in ()
*** 702,706 ****
  		  int link_res;
  		  link_res = link_to_maj_min_ino (file_hdr.c_name, 
! 				file_hdr.c_dev_maj, file_hdr.c_dev_maj,
  				file_hdr.c_ino);
  		  if (link_res == 0)
--- 702,706 ----
  		  int link_res;
  		  link_res = link_to_maj_min_ino (file_hdr.c_name, 
! 				file_hdr.c_dev_maj, file_hdr.c_dev_min,
  				file_hdr.c_ino);
  		  if (link_res == 0)


From pinard@progiciels-bpi.ca Sun May 17 23:50:36 1998
X-From-Line: nobody Tue Feb  4 09:46:48 1997
Received: by drip.colorado.edu (cu.generic.890828)
Received: from rtsq.grics.qc.ca (root@rtsq.grics.qc.ca [199.84.132.10]) by cygnus.com (8.6.12/8.6.9) with ESMTP id QAA16622 for <tromey@cygnus.com>; Mon, 3 Feb 1997 16:51:29 -0800
Received: by rtsq.grics.qc.ca (8.7.5/8.7.3) with UUCP id UAA28044 for tromey@cygnus.com; Mon, 3 Feb 1997 20:50:36 -0500
X-Authentication-Warning: rtsq.grics.qc.ca: uicule set sender to pinard@icule.progiciels-bpi.ca using -f
Received: by icule.progiciels-bpi.ca (8.7.6/8.7.3) id TAA03362; Mon, 3 Feb 1997 19:33:42 -0500
To: tromey@cygnus.com
Subject: Re: userspec.c
Reply-To: pinard@iro.umontreal.ca
References: <m1zq0p38y4.fsf@creche.cygnus.com>
X-Face: "b_m|CE6#'Q8fliQrwHl9K,]PA_o'*S~Dva{~b1n*)K*A(BIwQW.:LY?t4~xhYka_.LV?Qq
 `}X|71X0ea&H]9Dsk!`kxBXlG;q$mLfv_vtaHK_rHFKu]4'<*LWCyUe@ZcI6"*wB5M@[m<Ok5/cC^=
 CxDhg=TJi^o[E
Mime-Version: 1.0 (generated by tm-edit 7.90)
Content-Type: multipart/mixed;
 boundary="Multipart_Mon_Feb__3_19:33:41_1997-1"
From: pinard@progiciels-bpi.ca (=?ISO-8859-1?Q?Fran=E7ois?= Pinard)
Date: 03 Feb 1997 19:33:42 -0500
In-Reply-To: Tom Tromey's message of 1996-11-10 15:02:27-07:00
Message-Id: <oqwwsph0k9.fsf@icule.progiciels-bpi.ca>
X-Mailer: Gnus v5.4.10/Emacs 19.34
Xref: creche.cygnus.com mail.cpio:23
Lines: 181
X-Gnus-Newsgroup: mail.cpio:23   Mon Apr 14 00:03:29 1997

--Multipart_Mon_Feb__3_19:33:41_1997-1
Content-Type: text/plain; charset=US-ASCII

Tom Tromey <tromey@creche.cygnus.com> writes:

| Appended is my version of userspec.c, which appears in libit.  My
| version uses gettext, whereas the libit version does not.
| Probably the two versions need some merging.

Hi, Tom.  I made the following patch over your source, but I'm not really
satisfied yet with the result, as some details need more discussion.
I'll be back later about it.  Following the patch, you will find your
source as submitted.


--Multipart_Mon_Feb__3_19:33:41_1997-1
Content-Type: text/plain; charset=US-ASCII

--- userspec.c-orig	Mon Feb  3 19:29:14 1997
+++ userspec.c	Mon Feb  3 19:27:19 1997
@@ -12,27 +12,27 @@
    GNU General Public License for more details.
 
    You should have received a copy of the GNU General Public License
-   along with this program; if not, write to the Free Software
-   Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.  */
+   along with this program; if not, write to the Free Software Foundation,
+   Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.  */
 
 /* Written by David MacKenzie <djm@gnu.ai.mit.edu>.  */
 
-#ifdef HAVE_CONFIG_H
-#include <config.h>
+#if HAVE_CONFIG_H
+# include <config.h>
 #endif
 
 #ifdef __GNUC__
-#define alloca __builtin_alloca
+# define alloca __builtin_alloca
 #else
-#ifdef HAVE_ALLOCA_H
-#include <alloca.h>
-#else
-#ifdef _AIX
+# if HAVE_ALLOCA_H
+#  include <alloca.h>
+# else
+#  ifdef _AIX
  #pragma alloca
-#else
+#  else
 char *alloca ();
-#endif
-#endif
+#  endif
+# endif
 #endif
 
 #include <stdio.h>
@@ -41,27 +41,27 @@
 #include <grp.h>
 
 #if defined(STDC_HEADERS) || defined(HAVE_STRING_H)
-#include <string.h>
-#ifndef index
-#define index strchr
-#endif
+# include <string.h>
 #else
-#include <strings.h>
+# include <strings.h>
+# ifndef strchr
+#  define strchr index
+# endif
 #endif
 
-#ifdef STDC_HEADERS
-#include <stdlib.h>
+#if STDC_HEADERS
+# include <stdlib.h>
 #endif
 
-#ifdef HAVE_UNISTD_H
-#include <unistd.h>
+#if HAVE_UNISTD_H
+# include <unistd.h>
 #endif
 
 #if HAVE_LIBINTL_H
-#include <libintl.h>
-#define _(String) gettext (String)
+# include <libintl.h>
+# define _(String) gettext (String)
 #else
-#define _(String) String
+# define _(String) String
 #endif
 
 #ifndef _POSIX_VERSION
@@ -71,19 +71,19 @@
 #endif
 
 #ifdef _POSIX_SOURCE
-#define endpwent()
-#define endgrent()
+# define endpwent()
+# define endgrent()
 #endif
 
 /* Perform the equivalent of the statement `dest = strdup (src);',
    but obtaining storage via alloca instead of from the heap.  */
 
-#define V_STRDUP(dest, src)						\
+#define V_STRDUP(Dest, Src)						\
   do									\
     {									\
-      int _len = strlen ((src));					\
-      (dest) = (char *) alloca (_len + 1);				\
-      strcpy (dest, src);						\
+      int _len = strlen ((Src));					\
+      (Dest) = (char *) alloca (_len + 1);				\
+      strcpy (Dest, Src);						\
     }									\
   while (0)
 
@@ -142,9 +142,9 @@
   V_STRDUP (spec, spec_arg);
 
   /* Find the separator if there is one.  */
-  separator = index (spec, ':');
+  separator = strchr (spec, ':');
   if (separator == NULL)
-    separator = index (spec, '.');
+    separator = strchr (spec, '.');
 
   /* Replace separator with a NUL.  */
   if (separator != NULL)
@@ -252,10 +252,10 @@
 
   return error_msg;
 }
-
+
 #ifdef TEST
 
-#define NULL_CHECK(s) ((s) == NULL ? "(null)" : (s))
+# define NULL_CHECK(s) ((s) == NULL ? "(null)" : (s))
 
 int
 main (int argc, char **argv)
@@ -285,4 +285,4 @@
   exit (0);
 }
 
-#endif
+#endif /* TEST */


--Multipart_Mon_Feb__3_19:33:41_1997-1
Content-Type: application/octet-stream
Content-Disposition: attachment; filename="userspec.c-orig"
Content-Transfer-Encoding: base64


--Multipart_Mon_Feb__3_19:33:41_1997-1
Content-Type: text/plain; charset=US-ASCII


Hoping I got this MIME thing right :-).

--Multipart_Mon_Feb__3_19:33:41_1997-1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Fran=E7ois Pinard         ``Vivement GNU!''        pinard@iro.umontreal.c=
a
Support Programming Freedom, join our League!  Ask lpf@lpf.org for info!

--Multipart_Mon_Feb__3_19:33:41_1997-1--


From 100634.2261@compuserve.com Sun May 17 23:50:36 1998
X-From-Line: nobody Wed Feb  5 08:53:11 1997
Received: by drip.colorado.edu (cu.generic.890828)
Received: from darkstar.cygnus.com (darkstar.cygnus.com [192.203.188.2]) by cygnus.com (8.6.12/8.6.9) with ESMTP id XAA22998 for <tromey@drip.colorado.edu>; Tue, 4 Feb 1997 23:12:27 -0800
Received: from dub-img-2.compuserve.com (dub-img-2.compuserve.com [149.174.206.132]) by darkstar.cygnus.com (8.8.0/8.8.0) with SMTP id AAA01969 for <tromey@creche.cygnus.com>; Wed, 5 Feb 1997 00:09:07 -0700 (MST)
Received: by dub-img-2.compuserve.com (8.6.10/5.950515)
	id CAA13233; Wed, 5 Feb 1997 02:11:44 -0500
Date: 05 Feb 97 02:04:51 EST
From: Dombrofsky  Klaus-Peter <100634.2261@compuserve.com>
To: Tom Tromey <tromey@creche.cygnus.com>
Subject: Re: cpio / tar
Message-Id: <970205070450_100634.2261_BHL69-3@CompuServe.COM>
Status: RO
Xref: creche.cygnus.com mail.cpio:24
Lines: 13
X-Gnus-Newsgroup: mail.cpio:24   Mon Apr 14 00:03:40 1997

My OS is linux with kernel 2.0.25.

I think, if cpio is writing and the medium is full, then it writes a special
mark at the end of the tape. So when reading this tape, it reads this mark and
knows that it has reached the end of tape abd it asks for the next one.
So there might be a wrong writing of this mark in linux, because
multivolume-tapes created on another system can be read in linux.
I will take a look into the sources of the scsi-driver of linux.

Greetings from
Klaus-Peter



From tromey@creche.cygnus.com Sun May 17 23:50:37 1998
X-From-Line: nobody Fri Mar  7 09:45:23 1997
Received: by drip.colorado.edu (cu.generic.890828)
Received: (from tromey@localhost) by creche.cygnus.com (8.7.6/8.7.3) id JAA10510; Fri, 7 Mar 1997 09:44:20 -0700
To: tromey@drip.colorado.edu
Subject: [gnu.utils.bug] Problem with cpio 2.4.2
X-Zippy:  Well, I'm INVISIBLE AGAIN..  I might as well pay a visit to the
 LADIES ROOM...
X-Attribution:  Tom
Reply-To: tromey@cygnus.com
From: Tom Tromey <tromey@creche.cygnus.com>
Date: 07 Mar 1997 09:44:18 -0700
Message-Id: <m1sp274pp9.fsf@creche.cygnus.com>
X-Mailer: Red Gnus v0.34/Emacs 19.34
Xref: creche.cygnus.com mail.cpio:25
Lines: 47
X-Gnus-Newsgroup: mail.cpio:25   Mon Apr 14 00:05:58 1997


Tom
-- 
tromey@cygnus.com                 Member, League for Programming Freedom

------- Start of forwarded message -------
From: gnies@lanier.com (George Nies)
Message-ID: <199703061543.KAA18857@ss.lanier.com>
Subject: Problem with cpio 2.4.2
Date: Thu, 6 Mar 1997 10:43:38 -0500
Newsgroups: gnu.utils.bug

Hello

	I am attempting to use gnu cpio 2.4.2 to read archives created with
	cpio from DYNIX/ptx 2.1 and DYNIX/ptx 4.1 on Sequent computers.  Here
	is the problem:  If the archive contains hard links, _all_ of the
	files that had more than one referece become hard links to the last
	file in the archive with more than one reference.
	Here is an example:


    $ ls -l foo
    total 12
    drwxrwxr-x    2 gnies    users         512 Mar  6 09:18 .
    drwxr-xr-x   16 gnies    users        1024 Mar  6 09:46 ..
    -rw-rw-r--    2 gnies    users          11 Mar  6 09:18 BAR
    -rw-rw-r--    2 gnies    users          13 Mar  6 09:18 FOO
    -rw-rw-r--    2 gnies    users          11 Mar  6 09:18 bar
    -rw-rw-r--    2 gnies    users          13 Mar  6 09:18 foo
    $ find foo -print | /bin/cpio -oc | { cd bar ; /tmp/cpio -imud ; }
    $ ls -l bar/foo
    total 12
    drwxrwxr-x    2 gnies    users         512 Mar  6 10:29 .
    drwxrwxr-x    3 gnies    users         512 Mar  6 09:20 ..
    -rw-rw-r--    4 gnies    users          13 Mar  6 09:18 BAR
    -rw-rw-r--    4 gnies    users          13 Mar  6 09:18 FOO
    -rw-rw-r--    4 gnies    users          13 Mar  6 09:18 bar
    -rw-rw-r--    4 gnies    users          13 Mar  6 09:18 foo
     

	Is this a known bug?  Is there a work-around?
	Thanks for your time

		-George
------- End of forwarded message -------


From tromey@creche.cygnus.com Sun May 17 23:50:37 1998
X-From-Line: nobody Thu Mar 13 12:05:54 1997
Received: by drip.colorado.edu (cu.generic.890828)
Received: from creche.cygnus.com (creche.cygnus.com [192.203.188.26])
	by cygnus.com (8.8.5/8.8.5) with ESMTP id KAA14063
	for <tromey@cygnus.com>; Thu, 13 Mar 1997 10:31:29 -0800 (PST)
Received: (from tromey@localhost) by creche.cygnus.com (8.7.6/8.7.3) id LAA02844; Thu, 13 Mar 1997 11:31:24 -0700
To: tromey@drip.colorado.edu
Subject: [gnu.utils.bug] rmt on linux systems
X-Zippy:  Yow!  Now we can become alcoholics!
X-Attribution:  Tom
Reply-To: tromey@cygnus.com
From: Tom Tromey <tromey@creche.cygnus.com>
Date: 13 Mar 1997 11:31:24 -0700
Message-Id: <m1rahjve2r.fsf@creche.cygnus.com>
X-Mailer: Red Gnus v0.34/Emacs 19.34
Status: RO
Xref: creche.cygnus.com mail.cpio:26
Lines: 102
X-Gnus-Newsgroup: mail.cpio:26   Mon Apr 14 00:06:03 1997


Tom
-- 
tromey@cygnus.com                 Member, League for Programming Freedom

------- Start of forwarded message -------
Message-ID: <199703130010.QAA12186@penny.bluegum.wa.com>
Subject: rmt on linux systems
Date: Wed, 12 Mar 1997 16:10:43 -0800
From: lindsay@bluegum.wa.com (Lindsay Harris)
Newsgroups: gnu.utils.bug

Hi!  I have found a compatability problem with rmt on linux systems.
The problem is to do with using the "I" (ioctl) command.  This operates
by sending the contents of a struct mtop across the net in ascii,
then converting them to binary, placing in a struct mtop, and passing
this to ioctl() with the function MTIOCTOP.  The two parameters are
a function to perform (e.g. rewind, forward space "n" files etc)
and a count, if applicable.

The problem is a difference between the command numbers as defined
in Stevens' "Unix Network Programming" book and as defined in
linux's sys/mtio.h file (actually linux/mtio.h).  Stevens defines the
first seven values, saying there are others which are hardware dependent.
It would be nice to fix the linux definition of tape ioctl command
codes, but this is probably not going to happen overnight.  Longer
term solution is a better rmt, or at least one that fully/properly
defines the operation codes sent over the net.

This compability problem is limited to the "write EOF marks", "rewind"
and "rewind then go offline" operations only, at least as of 2.0.18.
The other operations defined in Stevens' book agree.

A work around is to have rmt use a table lookup to map the network
defined values to the local machine's values, whatever they be.
Very little overhead, and quite portable.  I have this working,
and the diff file is included.  The diff is against tar-1.11.8
sources.

Lindsay

--------------------------------------------------------------------
--- rmt.c.orig	Wed Mar 12 15:40:31 1997
+++ rmt.c	Wed Mar 12 15:41:44 1997
@@ -71,6 +71,44 @@
 #define	DEBUG2(File, Arg1, Arg2) \
   if (debug) fprintf(debug, File, Arg1, Arg2)
 
+
+#define	LH_PORTABLE	1
+#if LH_PORTABLE
+
+static	char	VER_rmt[] = "$Id: rmt.c,v 1.2 1997/03/12 22:53:43 lindsay Exp $";
+
+/*
+ *   This table translate the "network" opcodes for the MTIOCTOP ioctl
+ *  to those used on the local system.  The network values are as defined
+ *  in Stevens' "Unix Network Programming" book, p671.
+ */
+
+static  const int  IOctlXlate[] =
+{
+    MTWEOF,		/* Write an EOF record */
+    MTFSF,		/* Forward space file */
+    MTBSF,		/* Backward space file */
+    MTFSR,		/* Forward space record */
+    MTBSR,		/* Backward space record */
+    MTREW,		/* Rewind */
+    MTOFFL,		/* Rewind then then put drive offline */
+/* The following are not specified in Stevens' book, but agree with SVr3 */
+
+    MTNOP,		/* NOP, but set status */
+      MTNOP,		/* Should be MTCACHE - enable controller cache */
+      MTNOP,		/* Should be NTNOCACHE - disable controller cache */
+    MTFSS,		/* Forward space sequential file tape marks */
+    MTBSS,		/* Backward space over sequential file tape marks */
+    MTERASE,		/* ERASE THE TAPE!!! */
+    MTEOM,		/* Move to end of recorded memdium, ready to append */
+    MTRETEN,		/* Retension the tape */
+      MTNOP,		/* Should be MTCEOM - Clear end of medium flag */
+};
+
+#define	NUM_IOC_XLATE	(sizeof( IOctlXlate )/ sizeof( IOctlXlate[0] ))
+
+#endif  /* LH_PORTABLE */
+
 /*---.
 | ?  |
 `---*/
@@ -279,6 +317,10 @@
 	struct mtop mtop;
 
 	mtop.mt_op = atoi (op);
+#if LH_PORTABLE
+	if (mtop.mt_op >= 0 && mtop.mt_op < NUM_IOC_XLATE)
+	    mtop.mt_op = IOctlXlate [mtop.mt_op];
+#endif	/* LH_PORTABLE */
 	mtop.mt_count = atoi (count);
 	if (ioctl (tape, MTIOCTOP, (char *) &mtop) < 0)
 	  goto ioerror;
------- End of forwarded message -------


From pinard@iro.umontreal.ca Sun May 17 23:50:39 1998
X-From-Line: nobody Fri Mar 21 10:26:35 1997
Received: by drip.colorado.edu (cu.generic.890828)
Received: from rtsq.grics.qc.ca (root@rtsq.grics.qc.ca [199.84.132.10])
	by cygnus.com (8.8.5/8.8.5) with ESMTP id QAA29454
	for <tromey@cygnus.com>; Thu, 20 Mar 1997 16:55:38 -0800 (PST)
Received: by rtsq.grics.qc.ca (8.7.5/8.7.3) with UUCP id VAA20056; Thu, 20 Mar 1997 21:07:57 -0500
X-Authentication-Warning: rtsq.grics.qc.ca: uicule set sender to pinard@icule.progiciels-bpi.ca using -f
Received: by icule.progiciels-bpi.ca (8.8.4/8.7.3) id TAA06968; Thu, 20 Mar 1997 19:41:34 -0500
Date: Thu, 20 Mar 1997 19:41:34 -0500
Message-Id: <199703210041.TAA06968@icule.progiciels-bpi.ca>
From: "Frangois Pinard" <pinard@iro.umontreal.ca>
To: Tom Tromey <tromey@cygnus.com>
Subject: [olaf@toppoint.de: Several Problems (GNU Tar, cpio, smail)]
X-Face: "b_m|CE6#'Q8fliQrwHl9K,]PA_o'*S~Dva{~b1n*)K*A(BIwQW.:LY?t4~xhYka_.LV?Qq
 `}X|71X0ea&H]9Dsk!`kxBXlG;q$mLfv_vtaHK_rHFKu]4'<*LWCyUe@ZcI6"*wB5M@[m<Ok5/cC^=
 CxDhg=TJi^o[E
Mime-Version: 1.0 (generated by tm-edit 7.90)
Content-Type: multipart/mixed;
 boundary="Multipart_Thu_Mar_20_19:41:34_1997-1"
Status: RO
Xref: creche.cygnus.com mail.cpio:27
Lines: 48
X-Gnus-Newsgroup: mail.cpio:27   Mon Apr 14 00:06:27 1997

--Multipart_Thu_Mar_20_19:41:34_1997-1
Content-Type: text/plain; charset=US-ASCII

Another cpio problem.  The point 1., deleted, was referring to a problem in
tar, now solved.


--Multipart_Thu_Mar_20_19:41:34_1997-1
Content-Type: message/rfc822

From: olaf@toppoint.de (Olaf Schlueter)
Newsgroups: comp.os.linux.help
Subject: Several Problems (GNU Tar, cpio, smail)
Date: 13 Nov 1994 12:58:13 +0100
Organization: Toppoint Mailbox e.V.
NNTP-Posting-Host: localhost.toppoint.de
Mime-Version: 1.0
Content-Type: text/plain;  charset=ISO-8859-1
Keywords: tar cpio smail
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by cygnus.com id QAA29454

I have several problems with linux 1.0.9, ftape 1.13b and smail
3.1.28.  libc used is 4.5.26.

2.  Multi-Volume backup with GNU cpio does not work either
on /dev/ftape.  It does work on /dev/fd0.  If I try to read the
contents of the backup tape, cpio stops at the end of the first
volume with "No space left on device" error.

The tape drive used is a ancient Colorade DJ-10 QIC-40 tape drive
attached to the drive B: connector of my floppy controller.

--=20
Olaf Schl=FCter, Sandkuhle 4-6, 24103 Kiel, Germany, Toppoint Mailbox e.V.
"Wenn ich Klasse bin, m=F6chte ich auch nicht, da=DF jeder mein Freund wi=
rd."
Ein Kollege lernt C++.

--Multipart_Thu_Mar_20_19:41:34_1997-1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Fran=E7ois Pinard         ``Vivement GNU!''        pinard@iro.umontreal.ca
Support Programming Freedom, join our League!  Ask lpf@lpf.org for info!

--Multipart_Thu_Mar_20_19:41:34_1997-1--


From pinard@iro.umontreal.ca Sun May 17 23:50:39 1998
X-From-Line: nobody Fri Mar 21 10:26:35 1997
Received: by drip.colorado.edu (cu.generic.890828)
Received: from rtsq.grics.qc.ca (root@rtsq.grics.qc.ca [199.84.132.10])
	by cygnus.com (8.8.5/8.8.5) with ESMTP id QAA29456
	for <tromey@cygnus.com>; Thu, 20 Mar 1997 16:55:40 -0800 (PST)
Received: by rtsq.grics.qc.ca (8.7.5/8.7.3) with UUCP id VAA20053; Thu, 20 Mar 1997 21:07:48 -0500
X-Authentication-Warning: rtsq.grics.qc.ca: uicule set sender to pinard@icule.progiciels-bpi.ca using -f
Received: by icule.progiciels-bpi.ca (8.8.4/8.7.3) id TAA06945; Thu, 20 Mar 1997 19:36:09 -0500
Date: Thu, 20 Mar 1997 19:36:09 -0500
Message-Id: <199703210036.TAA06945@icule.progiciels-bpi.ca>
From: "Frangois Pinard" <pinard@iro.umontreal.ca>
To: Tom Tromey <tromey@cygnus.com>
Subject: [graham@tybj3.eglin.af.mil: Re: update on test CRC option]
X-Face: "b_m|CE6#'Q8fliQrwHl9K,]PA_o'*S~Dva{~b1n*)K*A(BIwQW.:LY?t4~xhYka_.LV?Qq
 `}X|71X0ea&H]9Dsk!`kxBXlG;q$mLfv_vtaHK_rHFKu]4'<*LWCyUe@ZcI6"*wB5M@[m<Ok5/cC^=
 CxDhg=TJi^o[E
Mime-Version: 1.0 (generated by tm-edit 7.90)
Content-Type: multipart/mixed;
 boundary="Multipart_Thu_Mar_20_19:36:08_1997-1"
Status: RO
Xref: creche.cygnus.com mail.cpio:28
Lines: 47
X-Gnus-Newsgroup: mail.cpio:28   Mon Apr 14 00:06:32 1997

--Multipart_Thu_Mar_20_19:36:08_1997-1
Content-Type: text/plain; charset=US-ASCII

Oops!  This one is related to the message I just sent.  I do not remember
why/how the letter got directed to me.



--Multipart_Thu_Mar_20_19:36:08_1997-1
Content-Type: message/rfc822

From: <graham@tybj3.eglin.af.mil>
Subject: Re: update on test CRC option
To: pinard@IRO.UMontreal.CA
Date: Thu, 25 Aug 1994 14:47:10 -0600 (CDT)
In-Reply-To: <199408251935.PAA14401@lagrande.iro.umontreal.ca> from "pinard@IRO.UMontreal.CA" at Aug 25, 94 03:35:24 pm
MIME-Version: 1.0

[...] a suggestion for GNU cpio.  I was suggesting that it would
be nice to have a way to test the CRC of each file in the archive
without actually extracting any data, and then mentioning that I'd
made some modifications to produce a crude version of this...that had
just one bug (it basically said every symbolic link was corrupted
because the link had a non-zero CRC, when cpio was expecting 0x0).
The update I was just trying to send to that person was to let
them know that I think I've fixed that bug, so if they do want to
include that code, it should now be a lot cleaner.  :-)

Later,
   --jim

--
73 DE N5IAL (/4)
graham@tybj3.eglin.af.mil  ||  jim@n5ial.mythical.com  ||  j.graham@ieee.org
Phone (office):  904-864-4080    Packet:  N5IAL@W4ZBB (Ft. Walton Beach, FL)



--Multipart_Thu_Mar_20_19:36:08_1997-1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Fran=E7ois Pinard         ``Vivement GNU!''        pinard@iro.umontreal.ca
Support Programming Freedom, join our League!  Ask lpf@lpf.org for info!

--Multipart_Thu_Mar_20_19:36:08_1997-1--


From pinard@iro.umontreal.ca Sun May 17 23:50:39 1998
X-From-Line: nobody Fri Mar 21 10:26:35 1997
Received: by drip.colorado.edu (cu.generic.890828)
Received: from rtsq.grics.qc.ca (root@rtsq.grics.qc.ca [199.84.132.10])
	by cygnus.com (8.8.5/8.8.5) with ESMTP id QAA29513
	for <tromey@cygnus.com>; Thu, 20 Mar 1997 16:55:57 -0800 (PST)
Received: by rtsq.grics.qc.ca (8.7.5/8.7.3) with UUCP id VAA20052; Thu, 20 Mar 1997 21:07:47 -0500
X-Authentication-Warning: rtsq.grics.qc.ca: uicule set sender to pinard@icule.progiciels-bpi.ca using -f
Received: by icule.progiciels-bpi.ca (8.8.4/8.7.3) id TAA06936; Thu, 20 Mar 1997 19:34:36 -0500
Date: Thu, 20 Mar 1997 19:34:36 -0500
Message-Id: <199703210034.TAA06936@icule.progiciels-bpi.ca>
From: "Frangois Pinard" <pinard@iro.umontreal.ca>
To: Tom Tromey <tromey@cygnus.com>
Subject: [graham@tybj3.eglin.af.mil: GNU cpio version 2.3 suggestion and problems]
X-Face: "b_m|CE6#'Q8fliQrwHl9K,]PA_o'*S~Dva{~b1n*)K*A(BIwQW.:LY?t4~xhYka_.LV?Qq
 `}X|71X0ea&H]9Dsk!`kxBXlG;q$mLfv_vtaHK_rHFKu]4'<*LWCyUe@ZcI6"*wB5M@[m<Ok5/cC^=
 CxDhg=TJi^o[E
Mime-Version: 1.0 (generated by tm-edit 7.90)
Content-Type: multipart/mixed;
 boundary="Multipart_Thu_Mar_20_19:34:34_1997-1"
Status: RO
Xref: creche.cygnus.com mail.cpio:29
Lines: 94
X-Gnus-Newsgroup: mail.cpio:29   Mon Apr 14 00:06:59 1997

--Multipart_Thu_Mar_20_19:34:34_1997-1
Content-Type: text/plain; charset=US-ASCII

Hi, Tom.  I had this message in my tar archives.  I do not think there is
anything there which might interest tar, so I'm deleting the message.  Take
a look before doing the same :-).  You may reply if you feel like it?


--Multipart_Thu_Mar_20_19:34:34_1997-1
Content-Type: message/rfc822

From: <graham@tybj3.eglin.af.mil>
Subject: GNU cpio version 2.3 suggestion and problems
To: bug-gnu-utils@prep.ai.mit.edu
Date: Thu, 25 Aug 1994 13:49:00 -0600 (CDT)
MIME-Version: 1.0

I've got both a suggestion for a future version of GNU cpio (which, on
systems where I'm using it, I've called gcpio to avoid conflicts with
the system's original cpio---my apologies if I refer to it as gcpio here)
and a problem I'm having that may or may not be specific to GNU cpio.

First, the suggestion.  :-)   I'm using GNU cpio for my backup routines
because of the ability to do a CRC check on the data, thus allowing me to
make sure that our backups are, in fact, valid copies.  However, unless
I've missed something, the only way you find out that a file in the
archive is damaged is when you try to recover it.  In other words, there
doesn't seem to be an option for just reading the tape and checking the
CRC values without actually extracting any files (and storing them on the
disk).

In my backup scripts, I like to write the data, then make an index of the
archive, and then check the archive for errors.  If a critical file weren't
archived correctly, I'd then want to make an extra copy somewhere, just to
be safe (the fact that I have multiple overlapping backups doesn't mean
much if the file is something really critical...my experience has been
that the more critical the data, the higher the probability that multiple
backups will fail).

Now, I have done something along this line, but it isn't clean by any
stretch of the imagination.  I basically took the function that extracts
the data, stripped out almost everything (too much, in fact...more about
that next), and made it simply calculate the CRC and move on.  It works for
almost everything, but when it finds symbolic links, it ends up calculating
a non-zero CRC, which is then listed as an error because it's expecting
0x0.  I'm pretty sure I just cut too much of the function out---there was
probably some code in there to check for symbolic links and give them some
special handling...but I missed it.  Anyways, if you'd like, I'd be happy
to send a copy of what I've got---it should be good for laughs, if nothing
else.  :-)

Does this sound like something worth including in the main distribution?
Did I, perhaps, miss an easier way to do this (I did RTFM, but I still
could have missed something)?

Ok, second bit.  On to the problems.  As I mentioned before, I'm not sure
if this is a GNU cpio problem, or a problem with the tape drive (it only
happens with one tape drive), but when I try to access our 8mm tape drive
on a Sun (/dev/rst12 ... compressed interface to the 8mm tape), the only
way I can do it is via the following:

   [find ....] | gcpio -oaB --format=crc | dd bs=5120 of=/dev/rst12
   dd bs=5120 if=/dev/rst12 | gcpio -itv

If, for example, I were to try

   gcpio -itv --block-size=5120 --file=/dev/rst12

I'd get one or two listings, and then ``gcpio: read error: I/O error''.

Trying to write to the tape gets similar results.  Now, other tape drives
(e.g., 4mm and 1/4" tape drives) work wonderfully.

Any ideas?

Thanks,
   --jim

--
73 DE N5IAL (/4)
graham@tybj3.eglin.af.mil  ||  jim@n5ial.mythical.com  ||  j.graham@ieee.org
Phone (office):  904-864-4080    Packet:  N5IAL@W4ZBB (Ft. Walton Beach, FL)



--Multipart_Thu_Mar_20_19:34:34_1997-1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Fran=E7ois Pinard         ``Vivement GNU!''        pinard@iro.umontreal.ca
Support Programming Freedom, join our League!  Ask lpf@lpf.org for info!

--Multipart_Thu_Mar_20_19:34:34_1997-1--


From pinard@iro.umontreal.ca Sun May 17 23:50:39 1998
X-From-Line: nobody Mon Apr 28 16:43:00 1997
Received: by drip.colorado.edu (cu.generic.890828)
Received: from rtsq.grics.qc.ca (root@rtsq.grics.qc.ca [199.84.132.10])
	by cygnus.com (8.8.5/8.8.5) with ESMTP id OAA00483
	for <tromey@cygnus.com>; Mon, 28 Apr 1997 14:41:40 -0700 (PDT)
Received: by rtsq.grics.qc.ca (8.7.5/8.7.3) with UUCP id RAA02145 for tromey@cygnus.com; Mon, 28 Apr 1997 17:30:43 -0400
X-Authentication-Warning: rtsq.grics.qc.ca: uicule set sender to pinard@icule.progiciels-bpi.ca using -f
Received: by icule.progiciels-bpi.ca (8.8.4/8.7.3) id OAA00780; Mon, 28 Apr 1997 14:25:52 -0400
To: tromey@cygnus.com
Subject: Re: Publishing tar 1.12 before automake 1.2 (?)
References: <oqhggy2cxn.fsf@icule.progiciels-bpi.ca> <m167x7ybc1.fsf@creche.cygnus.com>
X-Face: "b_m|CE6#'Q8fliQrwHl9K,]PA_o'*S~Dva{~b1n*)K*A(BIwQW.:LY?t4~xhYka_.LV?Qq
 `}X|71X0ea&H]9Dsk!`kxBXlG;q$mLfv_vtaHK_rHFKu]4'<*LWCyUe@ZcI6"*wB5M@[m<Ok5/cC^=
 CxDhg=TJi^o[E
Mime-Version: 1.0 (generated by tm-edit 7.90)
Content-Type: text/plain; charset=ISO-8859-1
From: pinard@iro.umontreal.ca (=?ISO-8859-1?Q?Fran=E7ois?= Pinard)
Date: 28 Apr 1997 14:25:50 -0400
In-Reply-To: Tom Tromey's message of 1997-04-27 23:18:22 -06:00
Message-Id: <oqzpujt369.fsf@icule.progiciels-bpi.ca>
X-Mailer: Gnus v5.4.46/Emacs 19.34
Content-Transfer-Encoding: quoted-printable
X-Mime-Autoconverted: from 8bit to quoted-printable by cygnus.com id OAA00483
Status: RO
Xref: creche.cygnus.com mail.cpio:31
Lines: 21
X-Gnus-Newsgroup: mail.cpio:31   Mon Apr 28 17:11:15 1997

Tom Tromey <tromey@creche.cygnus.com> writes:

| Hopefully it will be the stable release for a long time.  In fact,
| I intend to take some time off automake and work on cpio again.

I'm almost ready to do some intensive overhaul in I/O routines for GNU ta=
r,
and if you are willing that we collaborate in this, I would like that
we try making tar and cpio nearer one another, for the I/O interface.
On the other hand, I quite understand you have many other cats to whip
before you feel ready for such kind of aesthetical work! :-)

Please tell me a few weeks in advance, before you feel ready that we try
(moderately) such convergence.  I would be surprised if we get something
common and usable before a few releases on each side.

--=20
Fran=E7ois Pinard         ``Vivement GNU!''        pinard@iro.umontreal.c=
a
Support Programming Freedom, join our League!  Ask lpf@lpf.org for info!


From tromey@creche.cygnus.com Sun May 17 23:50:39 1998
X-From-Line: nobody Fri May 16 11:35:34 1997
Received: from cygnus.com (cygnus.com [205.180.230.20])
	by drip.colorado.edu (8.8.5/8.8.5) with ESMTP id KAA03128
	for <tromey@drip.colorado.edu>; Fri, 16 May 1997 10:37:40 -0600 (MDT)
Received: from creche.cygnus.com (creche.cygnus.com [192.203.188.26])
	by cygnus.com (8.8.5/8.8.5) with ESMTP id JAA19157
	for <tromey@cygnus.com>; Fri, 16 May 1997 09:37:36 -0700 (PDT)
Received: (from tromey@localhost) by creche.cygnus.com (8.7.6/8.7.3) id KAA01156; Fri, 16 May 1997 10:39:19 -0600
To: tromey@drip.colorado.edu
Subject: [gnu.utils.bug] cpio-2.4.2 doesn't compile with glibc-2.0.3
X-Zippy:  What UNIVERSE is this, please??
X-Attribution:  Tom
Reply-To: tromey@cygnus.com
From: Tom Tromey <tromey@creche.cygnus.com>
Date: 16 May 1997 10:39:18 -0600
Message-ID: <m1k9kzbccp.fsf@creche.cygnus.com>
X-Mailer: Red Gnus v0.34/Emacs 19.34
Status: O
Lines: 38
Xref: creche.cygnus.com mail.cygnus:3756 mail.gnits:1764 mail.cpio:33
X-Gnus-Newsgroup: mail.cpio:33   Fri May 16 11:35:34 1997


Tom
-- 
tromey@cygnus.com                 Member, League for Programming Freedom

------- Start of forwarded message -------
Date: Thu, 15 May 1997 23:11:30 +0200
Message-ID: <199705152111.XAA32309@isnogud.escape.de>
From: urs@isnogud.escape.de (Urs Thuermann)
Subject: cpio-2.4.2 doesn't compile with glibc-2.0.3
Newsgroups: gnu.utils.bug

My system is Linux-2.0.30, glibc-2.0.3, gcc-2.7.2.2

cpio-2.4.2 contains a declaration of sys_errlist which is incompatible
with glibc-2.0.3's include files.

Deleting the declaration makes cpio compile on Linux/glibc-2.0.3

--- cpio-2.4.2-orig/rmt.c	Wed Dec 20 17:29:07 1995
+++ cpio-2.4.2/rmt.c	Thu May 15 18:49:48 1997
@@ -75,7 +75,6 @@
 char count[SSIZE], mode[SSIZE], pos[SSIZE], op[SSIZE];
 
 extern errno;
-extern char *sys_errlist[];
 char resp[BUFSIZ];
 
 FILE *debug;



Is the declaration of sys_errlist in rmt.c necessary on other systems?


urs
------- End of forwarded message -------


From tromey@creche.cygnus.com Sun May 17 23:50:39 1998
X-From-Line: nobody Tue May 20 09:41:28 1997
Received: from creche.cygnus.com (creche.cygnus.com [192.203.188.26])
	by drip.colorado.edu (8.8.5/8.8.5) with ESMTP id JAA12651
	for <tromey@drip.colorado.edu>; Tue, 20 May 1997 09:25:15 -0600 (MDT)
Received: (from tromey@localhost) by creche.cygnus.com (8.7.6/8.7.3) id JAA00440; Tue, 20 May 1997 09:27:14 -0600
To: tromey@drip.colorado.edu
Subject: [gnu.utils.bug] Bug in cpio-2.4.2
X-Zippy:  I'm a nuclear submarine under the polar ice cap and I need a Kleenex!
X-Attribution:  Tom
Reply-To: tromey@cygnus.com
From: Tom Tromey <tromey@creche.cygnus.com>
Date: 20 May 1997 09:27:13 -0600
Message-ID: <m1sozicgfi.fsf@creche.cygnus.com>
X-Mailer: Red Gnus v0.34/Emacs 19.34
Lines: 42
Xref: creche.cygnus.com mail.cygnus:3831 mail.gnits:1775 mail.cpio:34
X-Gnus-Newsgroup: mail.cpio:34   Tue May 20 09:41:28 1997


Tom
-- 
tromey@cygnus.com                 Member, League for Programming Freedom

------- Start of forwarded message -------
Message-ID: <19970516141137.28778.qmail@zernez.palga.uucp>
From: jeholl@euronet.nl (Han Holl)
Subject: Bug in cpio-2.4.2
Date: Fri, 16 May 1997 16:11:37 +0200
Newsgroups: gnu.utils.bug


Hello,

The following is a patch (against cpio-2.4.2) to fix a rather nasty bug:
if a file grows _after_ cpio opened it, the extra bytes will be prepended
to the following file, rendering _all_ subsequent files invalid.

Personally, I would add
assert(input_size == 0)
to the start of copy_files_disk_to_tape, but that's a question of
taste.

Regards,

Han Holl


--- util.c.orig	Tue Jan 16 22:40:14 1996
+++ util.c	Fri May 16 14:27:08 1997
@@ -489,7 +489,7 @@
   while (num_bytes > 0)
     {
       if (input_size == 0)
-	if (rc = disk_fill_input_buffer (in_des, DISK_IO_BLOCK_SIZE))
+	if (rc = disk_fill_input_buffer (in_des, num_bytes))
 	  {
 	    if (rc > 0)
 	      error (0, 0, "File %s shrunk by %ld bytes, padding with zeros",
------- End of forwarded message -------


From tromey@creche.cygnus.com Sun May 17 23:50:39 1998
X-From-Line: nobody Fri May 23 00:17:02 1997
Received: from creche.cygnus.com (creche.cygnus.com [192.203.188.26])
	by drip.colorado.edu (8.8.5/8.8.5) with ESMTP id AAA21420
	for <tromey@drip.colorado.edu>; Fri, 23 May 1997 00:03:37 -0600 (MDT)
Received: (from tromey@localhost) by creche.cygnus.com (8.7.6/8.7.3) id AAA12913; Fri, 23 May 1997 00:05:32 -0600
To: tromey@drip.colorado.edu
Subject: [gnu.utils.bug] cpio 2.4.2 bug
X-Zippy:  I'm pretending I'm pulling in a TROUT!  Am I doing it correctly??
X-Attribution:  Tom
Reply-To: tromey@cygnus.com
From: Tom Tromey <tromey@creche.cygnus.com>
Date: 23 May 1997 00:05:31 -0600
Message-ID: <m1yb9667v8.fsf@creche.cygnus.com>
X-Mailer: Red Gnus v0.34/Emacs 19.34
Lines: 44
Xref: creche.cygnus.com mail.cygnus:3909 mail.gnits:1781 mail.cpio:37
X-Gnus-Newsgroup: mail.cpio:37   Fri May 23 00:17:02 1997


Tom
-- 
tromey@cygnus.com                 Member, League for Programming Freedom

------- Start of forwarded message -------
Date: Thu, 22 May 1997 19:19:04 -0700
Message-ID: <199705230219.TAA01672@osprey.grizzly.com>
From: markd@Grizzly.COM (Mark Diekhans)
Subject: cpio 2.4.2 bug
Newsgroups: gnu.utils.bug


cpio 2.4.2:

The --sparse option is incorrectly rejected as
a valid input option and allowed as a valid
output option.

*** main.c.ORG	Thu May 22 19:13:40 1997
--- main.c	Thu May 22 19:14:15 1997
***************
*** 387,393 ****
      {
        archive_des = 0;
        if (link_flag || reset_time_flag || xstat != lstat || append_flag
- 	  || sparse_flag
  	  || output_archive_name
  	  || (archive_name && input_archive_name))
  	usage (stderr, 2);
--- 387,392 ----
***************
*** 402,407 ****
--- 401,407 ----
      {
        archive_des = 1;
        if (argc != optind || create_dir_flag || rename_flag
+ 	  || sparse_flag
  	  || table_flag || unconditional_flag || link_flag
  	  || retain_time_flag || no_chown_flag || set_owner_flag
  	  || set_group_flag || swap_bytes_flag || swap_halfwords_flag

------- End of forwarded message -------


From tromey@creche.cygnus.com Sun May 17 23:50:40 1998
X-From-Line: nobody Tue Jun  3 11:53:31 1997
Received: from creche.cygnus.com (creche.cygnus.com [192.203.188.26])
	by drip.colorado.edu (8.8.5/8.8.5) with ESMTP id LAA18071
	for <tromey@drip.colorado.edu>; Tue, 3 Jun 1997 11:17:18 -0600 (MDT)
Received: (from tromey@localhost) by creche.cygnus.com (8.7.6/8.7.3) id LAA00877; Tue, 3 Jun 1997 11:19:15 -0600
To: tromey@drip.colorado.edu
Subject: [gnu.utils.bug] cpio 2.4.2 --no-absolute-filenames bugfix
X-Zippy:  ONE:  I will donate my entire ``BABY HUEY'' comic book collection
 to the downtown PLASMA CENTER..
 TWO:  I won't START a BAND called ``KHADAFY & THE HIT SQUAD''..
 THREE:  I won't ever TUMBLE DRY my FOX TERRIER again!!
X-Attribution:  Tom
Reply-To: tromey@cygnus.com
From: Tom Tromey <tromey@creche.cygnus.com>
Date: 03 Jun 1997 11:19:15 -0600
Message-ID: <m1206jhaek.fsf@creche.cygnus.com>
X-Mailer: Red Gnus v0.34/Emacs 19.34
Status: O
Lines: 45
Xref: creche.cygnus.com mail.cygnus:4191 mail.gnits:1854 mail.cpio:41
X-Gnus-Newsgroup: mail.cpio:41   Tue Jun  3 11:53:31 1997


Tom
-- 
tromey@cygnus.com                 Member, League for Programming Freedom

------- Start of forwarded message -------
Message-ID: <3390A00D.1C496B0@mail.utexas.edu>
Date: Sat, 31 May 1997 17:02:53 -0500
From: jharvell@mail.utexas.edu (Joe Harvell)
Organization: The University of Texas at Austin
Subject: cpio 2.4.2 --no-absolute-filenames bugfix
Newsgroups: gnu.utils.bug

When using the --no-absolute-filenames option when restoring files from
an archive stored in ustar format, cpio generates a segmentation
violation in free on line 501 in copyin.c.

I traced the code and determined that the reason for the error is that
file_hdr.c_name is static data (tar.c line 373) and was not allocated
with malloc.  I was not so thorough as to check whether file_hdr.c_name
points to static data for any use case of the program, so the patch I
have included below will introduce a serious memory leak if
file_hdr.c_name points into the heap for some uses.

diff copyin.c.old copyin.c.new
496,503c496
<           {
<             char *non_abs_name;
< 
<             non_abs_name = (char *) xmalloc (strlen (p) + 1);
<             strcpy (non_abs_name, p);
<             free (file_hdr.c_name);
<             file_hdr.c_name = non_abs_name;
<           }
---
>           file_hdr.c_name=p;



-- 
Joe Harvell
jharvell@mail.utexas.edu.
http://www.cs.utexas.edu./users/jharvell
------- End of forwarded message -------


From pinard@iro.umontreal.ca Sun May 17 23:50:40 1998
X-From-Line: nobody Wed Jun  4 00:23:44 1997
Received: from cygnus.com (cygnus.com [205.180.230.20])
	by drip.colorado.edu (8.8.5/8.8.5) with ESMTP id UAA21343
	for <tromey@drip.colorado.edu>; Tue, 3 Jun 1997 20:00:52 -0600 (MDT)
Received: from rtsq.grics.qc.ca (root@rtsq.grics.qc.ca [199.84.132.10])
	by cygnus.com (8.8.5/8.8.5) with ESMTP id SAA24857
	for <tromey@cygnus.com>; Tue, 3 Jun 1997 18:59:35 -0700 (PDT)
Received: by rtsq.grics.qc.ca (8.7.5/8.7.3) with UUCP id WAA26779; Tue, 3 Jun 1997 22:06:13 -0400
X-Authentication-Warning: rtsq.grics.qc.ca: uicule set sender to pinard@icule.progiciels-bpi.ca using -f
Received: by icule.progiciels-bpi.ca (8.8.4/8.7.3) id WAA06421; Tue, 3 Jun 1997 22:02:33 -0400
Date: Tue, 3 Jun 1997 22:02:33 -0400
Message-Id: <199706040202.WAA06421@icule.progiciels-bpi.ca>
From: "Franois Pinard" <pinard@iro.umontreal.ca>
To: Tom Tromey <tromey@cygnus.com>
Subject: ustar compatibility, from cpio distribution
X-Face: "b_m|CE6#'Q8fliQrwHl9K,]PA_o'*S~Dva{~b1n*)K*A(BIwQW.:LY?t4~xhYka_.LV?Qq
 `}X|71X0ea&H]9Dsk!`kxBXlG;q$mLfv_vtaHK_rHFKu]4'<*LWCyUe@ZcI6"*wB5M@[m<Ok5/cC^=
 CxDhg=TJi^o[E
Mime-Version: 1.0 (generated by tm-edit 7.106)
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by drip.colorado.edu id UAA21343
Status: RO
Lines: 14
Xref: creche.cygnus.com mail.gnits:1860 mail.cpio:42
X-Gnus-Newsgroup: mail.cpio:42   Wed Jun  4 00:23:44 1997

Hello, Tom.  The cpio distribution, somewhere, maybe in README (?), has this
comment:

   GNU tar recognizes standard "ustar" archives, such as GNU cpio produces,
   but won't use the path prefix.  You will lose the beginnings of paths
   that are longer than 100 characters.

This is not true anymore for tar after 1.12, which now should recognise
ustar archives.  You may amend the comment to say so if you want.

-- 
Franois Pinard                                 pinard@iro.umontreal.ca
Support Programming Freedom, join our League!  Ask lpf@lpf.org for info


From js@cs.tu-berlin.de Sun May 17 23:50:40 1998
X-From-Line: nobody Wed Jun  4 12:50:29 1997
Received: from cygnus.com (cygnus.com [205.180.230.20])
	by drip.colorado.edu (8.8.5/8.8.5) with ESMTP id KAA23778
	for <tromey@drip.colorado.edu>; Wed, 4 Jun 1997 10:35:44 -0600 (MDT)
Received: from degusse.iro.umontreal.ca (degusse.IRO.UMontreal.CA [132.204.32.45])
	by cygnus.com (8.8.5/8.8.5) with ESMTP id JAA17458;
	Wed, 4 Jun 1997 09:35:40 -0700 (PDT)
Received: (from daemon@localhost) by degusse.iro.umontreal.ca (8.7.5/8.7.3) id MAA09350 for tar-forum-outgoing; Wed, 4 Jun 1997 12:35:28 -0400 (EDT)
Received: from mail.cs.tu-berlin.de (root@mail.cs.tu-berlin.de [130.149.17.13]) by degusse.iro.umontreal.ca (8.7.5/8.7.3) with ESMTP id MAA09337 for <tar-forum@IRO.UMontreal.CA>; Wed, 4 Jun 1997 12:35:23 -0400 (EDT)
Received: from kraftbus.cs.tu-berlin.de (js@kraftbus.cs.tu-berlin.de [130.149.25.72])
	by mail.cs.tu-berlin.de (8.8.5/8.8.5) with ESMTP id SAA03250;
	Wed, 4 Jun 1997 18:35:20 +0200 (MET DST)
From: Joerg Schilling <js@cs.tu-berlin.de>
Received: (from js@localhost)
	by kraftbus.cs.tu-berlin.de (8.8.5/8.8.5) id SAA17525;
	Wed, 4 Jun 1997 18:35:18 +0200 (MET DST)
Date: Wed, 4 Jun 1997 18:35:18 +0200 (MET DST)
Message-Id: <199706041635.SAA17525@kraftbus.cs.tu-berlin.de>
To: fshimon@iil.intel.com, tar-forum@IRO.UMontreal.CA
Subject: Re: Bug (?) in GNU tar
Sender: owner-tar-forum@IRO.UMontreal.CA
Precedence: bulk
Reply-To: tar-forum@IRO.UMontreal.CA
Status: RO
Xref: creche.cygnus.com mail.cpio:43
Lines: 46
X-Gnus-Newsgroup: mail.cpio:43   Wed Jun  4 12:57:32 1997

>The correction is not easy, but is planned.  I was intending to POSIXify
>tar in the long run, and this is discussed in doc/tar.texi, under the
?`posix' node (search for "@node posix", or in Info, do "g posix RET").
>
>In fact, I'm taking this opportunity for sharing with tar forum members
>the latest news about this.  After the long lasting problems introduced
>by POSIX incompatibilities in current GNU tar format, I was quite strongly
>motivated to do it right, this time.  However, I received orders from the
>FSF (you know who! :-) to introduce new incompatibilities in the format
>to come.  The reason is that the FSF wants not only mtime, but also atime
>and ctime in each header entry, while POSIX has only room for mtime.
>There are extension mechanisms in POSIX for implementors wanting to add
>their own headers, but so far that I understand the matter, this would
>require at least one extra header block (512 bytes) per file in the
>uncompressed archive, just for being fully conformant to the extension
>mechanism.  The FSF does not want the extra block, but does not want to
>give up either on atime/ctime, the only choice left then being to have
>header entries still not strictly POSIX.  I'm not comfortable with that.

Do you remenber my mail from about a month ago?

This exactly what I am doing in star with the currently default 'xstar'
archive format that I introduced 3 years ago.

It ***is*** possible to do this and be POSIX compliant.

I strongly recommend you to have a look at star and try to implement the
xstar format for GNU tar too. Xstar format is a merge of all
goodies of my very old (1986) star format, the GNU tar extensions and
the POSIX 1003.1 standard archive format.

I am copying the atime and ctime fields into the end of the 155 byte
space for the file name prefix. These fields will be separated by 
a null byte from the filename prefix and therefore will not harm a
true (only) POSIX tar.

In addition, it will be most unlikely (at least from my tests) that 
you will need the space bejond the 130 char prefix that may be used
with the xstar format. If a filename is too long for that, I use 
a super long filename header, otherwise I use POSIX filename splitting.


Joerg

http://www.fokus.gmd.de/usr/schilling ftp://ftp.fokus.gmd.de/pub/unix


From farzin@blitz.net Sun May 17 23:50:40 1998
X-From-Line: nobody Mon Jun  9 16:55:53 1997
Received: from cygnus.com (cygnus.com [205.180.230.20])
	by drip.colorado.edu (8.8.5/8.8.5) with ESMTP id QAA10627
	for <tromey@drip.colorado.edu>; Mon, 9 Jun 1997 16:40:50 -0600 (MDT)
Received: from cumulus.blitz.de (cumulus.blitz.de [195.30.20.19])
	by cygnus.com (8.8.5/8.8.5) with ESMTP id PAA20844
	for <tromey@cygnus.com>; Mon, 9 Jun 1997 15:40:44 -0700 (PDT)
Received: (from uucp@localhost) by cumulus.blitz.de (8.8.5/8.7.3) with UUCP id AAA05541 for tromey@cygnus.com; Tue, 10 Jun 1997 00:40:36 +0200
Received: (from farzin@localhost)
	by atefi.blitz.net (8.8.5/8.8.5) id AAA28675
	for tromey@cygnus.com; Tue, 10 Jun 1997 00:31:52 +0200
From: Farzin Atefi <farzin@blitz.net>
Message-Id: <199706092231.AAA28675@atefi.blitz.net>
Subject: Re: gnu cpio
To: tromey@cygnus.com
Date: Tue, 10 Jun 1997 00:31:52 +0200 (MET DST)
In-Reply-To: <m1yb8j2zsw.fsf@creche.cygnus.com> from "Tom Tromey" at Jun 9, 97 04:10:07 pm
X-Mailer: ELM [version 2.4 PL25]
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Status: RO
Lines: 33
Xref: creche.cygnus.com mail.gnits:1896 mail.cpio:46
X-Gnus-Newsgroup: mail.cpio:46   Mon Jun  9 16:55:53 1997

Tom Tromey wrote:
> 
> Farzin> Isn't it clear from my message that this can't be the problem?
> 
> I hadn't read it.  I didn't have time when it showed up, so I just
> wanted to see if Ulrich's suggestion was right.
> 
> I still have your report.
> 
> cpio doesn't do the right thing if a file changes size while it is
> being written.  It will generate corrupt archives in this case.
> 
> This is a known problem.  I think I have a patch somewhere that
> purports to fix it, but I can't find it right now.
> 
> If you like, I'll look for it again later.
> 
Please do send me the patch as soon as possible. All my
backup scripts depend on cpio. I've been using cpio for ages,
well before the times of GNU and Linux. Tar used to be very
buggy, specially with symbolic links. Has cpio become so
out of fashion that nobody bothers to fix the bugs?
What do you suggest as a backup programm for Linux?
Do you know about this problem on other UNIX systems?

Cheers,
Farzin

-- 
Farzin Atefi
Riegelhofgasse 6, 96049 Bamberg, GERMANY
Voice/Fax: +49 951 52305


From js@cs.tu-berlin.de Sun May 17 23:50:40 1998
X-From-Line: nobody Wed Jun 18 09:22:15 1997
Received: from cygnus.com (cygnus.com [205.180.230.20])
	by drip.colorado.edu (8.8.5/8.8.5) with ESMTP id IAA11173
	for <tromey@drip.colorado.edu>; Wed, 18 Jun 1997 08:34:52 -0600 (MDT)
Received: from degusse.iro.umontreal.ca (degusse.IRO.UMontreal.CA [132.204.32.45])
	by cygnus.com (8.8.5/8.8.5) with ESMTP id HAA07743;
	Wed, 18 Jun 1997 07:34:50 -0700 (PDT)
Received: (from daemon@localhost) by degusse.iro.umontreal.ca (8.7.5/8.7.3) id KAA03667 for tar-forum-outgoing; Wed, 18 Jun 1997 10:33:46 -0400 (EDT)
Received: from mail.cs.tu-berlin.de (root@mail.cs.tu-berlin.de [130.149.17.13]) by degusse.iro.umontreal.ca (8.7.5/8.7.3) with ESMTP id KAA03651 for <tar-forum@IRO.UMontreal.CA>; Wed, 18 Jun 1997 10:33:39 -0400 (EDT)
Received: from kraftbus.cs.tu-berlin.de (js@kraftbus.cs.tu-berlin.de [130.149.25.72])
	by mail.cs.tu-berlin.de (8.8.6/8.8.6) with ESMTP id QAA25005
	for <tar-forum@IRO.UMontreal.CA>; Wed, 18 Jun 1997 16:33:35 +0200 (MET DST)
From: Joerg Schilling <js@cs.tu-berlin.de>
Received: (from js@localhost)
	by kraftbus.cs.tu-berlin.de (8.8.6/8.8.5) id QAA19832
	for tar-forum@IRO.UMontreal.CA; Wed, 18 Jun 1997 16:33:33 +0200 (MET DST)
Date: Wed, 18 Jun 1997 16:33:33 +0200 (MET DST)
Message-Id: <199706181433.QAA19832@kraftbus.cs.tu-berlin.de>
To: tar-forum@IRO.UMontreal.CA
Subject: Star-1.1 source has been released
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-tar-forum@IRO.UMontreal.CA
Precedence: bulk
Reply-To: tar-forum@IRO.UMontreal.CA
Xref: creche.cygnus.com mail.cpio:47
Lines: 131
X-Gnus-Newsgroup: mail.cpio:47   Wed Jun 18 09:42:13 1997

Just in case someone is interested in other tar implementations.
I just released a new version of "star".

Joerg

-----------------------------------------------
Star is the fastest tar archiver for UNIX
Star has many improvements compared to other tar imlementations.
See below for a short description of the highlight of star.

Star is located on:

ftp://ftp.fokus.gmd.de/pub/unix/star

Changes since star-1.0:
	Better manual, better examples in the manual.
	Add a -xdir flag to force extraction of directories regardless of time stamp.
	Changed max number of patterns from 10 to 100.
	First implementation of the -z flag.
	Don't dump archive if it is a file.
	Finally implement -C option even working in extract mode.
	Star now defaults to 100% ansi if it is called as 'ustar'
		(add ustar hardlink to star)
	Fifo size may be controlled by STAR_FIFO_SIZE environment
	Diff behaviour optimized to give less misleading output
	EOF error messages better for better understanding of GNU tar EOF bug
	Limit name length for old tar & GNU tar to 99 chars
	New options -force_remove -ask_remove -remove_first -remove_recursive
	New option -nullout to get the size of the archive as fast as possible
		really as fast as with find(1)
	Many speed enhancements: Now using 40% less user CPU time in general.
		up to 400% on filesystems with many hard links (news)
	Bug fix for -sparse (star & xstar format)
	Compiles again on AIX (use setenv COPTX -DNO_FLOATINGPOINT before)

Revision history (short)

1982	First version on UNOS (extract only)
1985	Port to UNIX (fully funtional version)
1985	Added pre Posix method of handling special files/devices
1986	First experiments with fifo as external process.
1993	Remote tape access
1993	diff option
1994	Fifo with shared memory integrated into star
1994	Very long filenames and sparse files
1994	Gnutar and Ustar(Posix) handling added
1994	Xstar format (extended Posix) defined and introduced
1995	Ported to many platforms

Supported platforms:

SunOS 4.x, Solaris (SunOS 5.x), Linux, HP-UX, DG/UX, IRIX, AIX, FreeBSD, NetBSD

Joerg

-------------------------------------------------------------
Star is the fastest known implementation of a tar archiver.
Star is able to make backups with more than 12MB/s if the
disk and tape drive support such a speed. This is more than
double the speed that ufsdump will get.
Ampex got 13.5 MB/s with their new DLT tape drive.
Ufsdump got a maximum speed of about 6MB/s with the same hardware.

Star development started 1982, development is still in progress.
The current version of star is stable and 
I never did my backups with other tools than star.

Its main advantages over other tar implementations are:

	fifo			- keeps the tape streaming.
				  This gives you faster backups than
				  you can achieve with ufsdump, if the
				  size of the filesystem is > 1 GByte.

	pattern matcher		- for a convenient user interface
				  (see manual page for more details).
				  To archive/extract a subset of files.

	sophisticated diff	- user tailorable interface for comparing
				  tar archives against file trees
				  This is one of the most interesting parts
				  of the star implementation.

	no namelen limitation	- Pathnames up to 1024 Bytes may be archived.
				  (The same limitation applies to linknames)
				  This limit may be expanded in future
				  without changing the method to record long names.

	deals with all 3 times	- stores/restores all 3 times of a file
				  (even creation time)
				  may reset access time after doing backup

	does not clobber files	- more recent copies on disk will not be 
				  clobbered from tape
				  This may be the main advantage over other
				  tar implementations. This allows
				  automatically repairing of corruptions
				  after a crash & fsck (Check for differences
				  after doing this with the diff option).

	automatic byte swap	- star automatically detects swapped archives
				  and transparently reads them the right way

	automatic format detect	- star automatically detects several common
				  archive formats and adopts to them.
				  Supported archive types are:
				  Old tar, gnu tar, ansi tar, star.

	fully ansi compatible	- Star is fully ANSI/Posix 1003.1 compatible.
				  See README.otherbugs for a complete description
				  of bugs found in other tar implementations.

Have a look at the manual page, it is included in the distribution.

Author:

Joerg Schilling
Seestr. 110
D-13353 Berlin
Germany

Email: 	joerg@schily.isdn.cs.tu-berlin.de, js@cs.tu-berlin.de
	schilling@fokus.gmd.de

Please mail bugs and suggestions to me.
-- 
EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jrg Schilling D-13353 Berlin
      js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
      jes@fokus.gmd.de			(work) chars I am J"org Schilling
URL:  http://www.fokus.gmd.de/usr/schilling    ftp://ftp.fokus.gmd.de/pub/unix


From tromey@cygnus.com Sun May 17 23:50:40 1998
X-From-Line: nobody Sat Oct 25 13:20:11 1997
Received: from creche.cygnus.com (creche.cygnus.com [192.203.188.26])
	by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id LAA10126
	for <tromey@cygnus.com>; Sat, 25 Oct 1997 11:31:48 -0700 (PDT)
Received: (from tromey@localhost) by creche.cygnus.com (8.7.6/8.7.3) id MAA21400; Sat, 25 Oct 1997 12:36:23 -0600
To: tromey@cygnus.com
Subject: [gnu.utils.bug] bugs in cpio
X-Zippy:  Your CHEEKS sit like twin NECTARINES above a MOUTH that knows no BOUNDS --
X-Attribution:  Tom
Reply-To: tromey@cygnus.com
From: Tom Tromey <tromey@cygnus.com>
Date: 25 Oct 1997 11:36:22 -0700
Message-ID: <m1vhylr8pl.fsf@creche.cygnus.com>
X-Mailer: Red Gnus v0.34/Emacs 19.34
Content-Type: text
X-UIDL: 3b318e553c142d3a6c98ec8121702b50
Status: O
Lines: 107
Xref: creche.cygnus.com mail.cygnus:8726 mail.gnits:2319 mail.cpio:56
X-Gnus-Newsgroup: mail.cpio:56   Sat Oct 25 13:20:11 1997


Tom
-- 
tromey@cygnus.com                 Member, League for Programming Freedom

------- Start of forwarded message -------
From: sp128@ibm.net (Steve Peurifoy)
Message-ID: <199710250440.WAA03262@axel.home>
Subject: bugs in cpio
Date: Fri, 24 Oct 1997 22:40:37 -0600
Newsgroups: gnu.utils.bug

Hi,

I've got a couple of bugs to report on cpio.  These were discovered in
version 2.3, but based on a look at the code they still appear to be
present in 2.4.2.

The first is that on a system that doesn't support lchown, cpio defines
lchown to be chown.  The result is that when restoring an archive or
copying a tree which includes both a file and, later in the input, a
symbolic link to that file, cpio does a chown on the link based on the
uid/gid of the source link which changes the uid/gid of the target
file.  The owner/group of the file can thus be incorrectly set.  A
patch to correct this (again based on 2.3, but it's not hard to see
where it goes in 2.4.2) follows.

*** copyin.c    1997/10/23 03:43:17     1.1
--- copyin.c    1997/10/23 03:50:11     1.2
***************
*** 903,914 ****
--- 903,916 ----
                    link_name = NULL;
                    continue;
                  }
+ #ifdef HAVE_LCHOWN
                if (!no_chown_flag)
                  if ((lchown (file_hdr.c_name,
                               set_owner_flag ? set_owner : file_hdr.c_uid,
                           set_group_flag ? set_group : file_hdr.c_gid) < 0)
                      && errno != EPERM)
                    error (0, errno, "%s", file_hdr.c_name);
+ #endif
                free (link_name);
                link_name = NULL;
              }

*** copypass.c  1997/10/23 03:43:17     1.1
--- copypass.c  1997/10/23 03:50:11     1.2
***************
*** 347,352 ****
--- 347,353 ----
              continue;
            }
  
+ #ifdef HAVE_LCHOWN
          /* Set the attributes of the new link.  */
          if (!no_chown_flag)
            if ((lchown (output_name.ds_string,
***************
*** 354,359 ****
--- 355,361 ----
                      set_group_flag ? set_group : in_file_stat.st_gid) < 0)
                && errno != EPERM)
              error (0, errno, "%s", output_name.ds_string);
+ #endif
          free (link_name);
        }
  #endif

The second bug has to do with hard links between files created by
cpio -i or cpio -p.  If an archive or tree with a fairly large number
of hard linked files is input to cpio, some of the links will be broken
in the destination.  This is due to what looks like a cut'n'paste error
in the link hash lookup code.  A patch follows.

*** util.c      1997/10/24 17:55:26     1.1
--- util.c      1997/10/24 20:35:03     1.2
***************
*** 601,608 ****
           temp = (temp + 1) % hash_size)
        {
          if (hash_table[temp]->inode == node_num
!             && hash_table[start]->major_num == major_num
!             && hash_table[start]->minor_num == minor_num)
            return hash_table[temp]->file_name;
        }
      }
--- 601,608 ----
           temp = (temp + 1) % hash_size)
        {
          if (hash_table[temp]->inode == node_num
!             && hash_table[temp]->major_num == major_num
!             && hash_table[temp]->minor_num == minor_num)
            return hash_table[temp]->file_name;
        }
      }

Hope this is useful.

Regards,

Steve Peurifoy
sp128@ibm.net

------- End of forwarded message -------


From tromey@cygnus.com Sun May 17 23:50:40 1998
X-From-Line: nobody Wed Jan 14 13:20:28 1998
Received: from creche.cygnus.com (creche.cygnus.com [192.203.188.26])
	by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id KAA21310
	for <tromey@cygnus.com>; Wed, 14 Jan 1998 10:00:13 -0800 (PST)
Received: (from tromey@localhost) by creche.cygnus.com (8.7.6/8.7.3) id KAA29372; Wed, 14 Jan 1998 10:57:21 -0700
To: tromey@cygnus.com
Subject: [gnu.utils.bug] bug in cpio-2.4.2: mangled archive if a file grows during backup
X-Zippy:  This MUST be a good party -- My RIB CAGE is being painfully
 pressed up against someone's MARTINI!!
X-Attribution:  Tom
Reply-To: tromey@cygnus.com
From: Tom Tromey <tromey@cygnus.com>
Date: 14 Jan 1998 10:57:20 -0700
Message-ID: <m14t37djlr.fsf@creche.cygnus.com>
X-Mailer: Red Gnus v0.34/Emacs 19.34
Content-Type: text
X-UIDL: 3b43dcf2d4b6a06bd18aeb7448952963
Status: O
Xref: creche.cygnus.com mail.cpio:73
Lines: 126
X-Gnus-Newsgroup: mail.cpio:73   Wed Jan 14 13:23:27 1998


Tom
------- Start of forwarded message -------
From: lampa@fee.vutbr.cz (Petr Lampa)
Message-ID: <199801141642.RAA24752@boco.fee.vutbr.cz>
Subject: bug in cpio-2.4.2: mangled archive if a file grows during backup
Date: Wed, 14 Jan 1998 17:42:30 +0100
Newsgroups: gnu.utils.bug


If any file grows during backup, then copy_files_disk_to_tape() and
copy_files_disk_to_disk() leave input_size nonzero. Nonzero value
of input_size after disk file backup is not checked anywhere and
growed bit of this file is used as the beginning of the next file,
so the first block is mangled (see copy_files_disk_to_tape() - 
disk_fill_input_buffer() is called only when input_size is 0).
You can easily verify this behaviour using crc format dump:

while true; do echo some long line; done >growing_file &
find . -depth -print|cpio -o -H crc >backup.cpio	(NO WARNING HERE)
cpio -ivt --only-verify-crc <backup.cpio		(but archive is BAD)
-rw-------   1 root     daemon     495962 Jan 14 17:34 growing_file
-r--------   1 root     daemon      39504 Nov 30  1994 copyin.c
/usr/local/bin/cpio: copyin.c: checksum error (0x2f4edb, should be 0x2f3a4f)
-r--------   1 root     daemon      22867 Jan 10  1996 copyout.c
/usr/local/bin/cpio: copyout.c: checksum error (0x1bd6a8, should be 0x1bd466)
-r--------   1 root     daemon      14706 Jan  8  1996 copypass.c
/usr/local/bin/cpio: copypass.c: checksum error (0x11d6e7, should be 0x11d627)
-rw-------   1 root     wheel        1342 Apr 29  1993 defer.c
/usr/local/bin/cpio: defer.c: checksum error (0x1b5a8, should be 0x1b7dd)
.. (all remaining files are bad...)

Here is suggested patch:

diff -rc cpio-2.4.2/copyout.c cpio-2.4.2.new/copyout.c
*** cpio-2.4.2/copyout.c	Wed Jan 10 17:10:45 1996
--- cpio-2.4.2.new/copyout.c	Wed Jan 14 17:09:44 1998
***************
*** 393,398 ****
--- 393,403 ----
  
  	      tape_pad_output (out_file_des, file_hdr.c_filesize);
  
+               if (input_size > 0) {
+                 error(0, 0, "%s: file grows during backup", input_name.ds_string);
+                 input_size = 0;
+               }
+ 
  	      if (close (in_file_des) < 0)
  		error (0, errno, "%s", input_name.ds_string);
  	      if (reset_time_flag)
***************
*** 793,798 ****
--- 798,807 ----
  #endif
  
    tape_pad_output (out_file_des, file_hdr.c_filesize);
+   if (input_size > 0) {
+     error(0, 0, "%s: file grows during backup", header->c_name);
+     input_size = 0;
+   }
  
    if (close (in_file_des) < 0)
      error (0, errno, "%s", header->c_name);
diff -rc cpio-2.4.2/copypass.c cpio-2.4.2.new/copypass.c
*** cpio-2.4.2/copypass.c	Mon Jan  8 22:59:05 1996
--- cpio-2.4.2.new/copypass.c	Wed Jan 14 17:08:47 1998
***************
*** 171,176 ****
--- 171,180 ----
  
  	      copy_files_disk_to_disk (in_file_des, out_file_des, in_file_stat.st_size, input_name.ds_string);
  	      disk_empty_output_buffer (out_file_des);
+               if (input_size > 0) {
+                 error(0, 0, "%s: file grows during backup", input_name.ds_string);
+                 input_size = 0;
+               }
  	      if (close (in_file_des) < 0)
  		error (0, errno, "%s", input_name.ds_string);
  	      if (close (out_file_des) < 0)
diff -rc cpio-2.4.2/util.c cpio-2.4.2.new/util.c
*** cpio-2.4.2/util.c	Tue Jan 16 22:40:14 1996
--- cpio-2.4.2.new/util.c	Wed Jan 14 17:06:17 1998
***************
*** 485,490 ****
--- 485,491 ----
    long original_num_bytes;
  
    original_num_bytes = num_bytes;
+   input_size = 0;	/* PL */
  
    while (num_bytes > 0)
      {
***************
*** 532,537 ****
--- 533,539 ----
    long original_num_bytes;
    int rc;
  
+   input_size = 0; /* PL */
    original_num_bytes = num_bytes;
    while (num_bytes > 0)
      {
--------------------

And the result of the patch:

find . -depth -print|cpio -o -H crc >backup.cpio
cpio: ./growing_file: file grows during backup		(WARNING)
cpio -ivt --only-verify-crc <backup.cpio
-rw-------   1 root     daemon     495962 Jan 14 17:34 growing_file
-r--------   1 root     daemon      39504 Nov 30  1994 copyin.c
.. (archive is OK)


Your sincerely,

							Petr Lampa

-- 
Department of Computer Science and Engineering  E-mail: lampa@fee.vutbr.cz
Faculty of El. Engineering and Comp. Science	Phone: (+420 5) 7275/225,111
Technical University of Brno			Fax:  (+420 5) 41211141
Bozetechova 2, 612 66 Brno, Czech Republic
------- End of forwarded message -------


From tromey@cygnus.com Sun May 17 23:50:40 1998
X-From-Line: nobody Thu Jan 15 10:48:16 1998
Received: from creche.cygnus.com (creche.cygnus.com [192.203.188.26])
	by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id JAA09532
	for <tromey@cygnus.com>; Thu, 15 Jan 1998 09:29:30 -0800 (PST)
Received: (from tromey@localhost) by creche.cygnus.com (8.7.6/8.7.3) id KAA02448; Thu, 15 Jan 1998 10:28:05 -0700
To: tromey@cygnus.com
Subject: [gnu.utils.bug] cpio 2.4.2 (error and enhancement)
X-Zippy:  Hello, GORRY-O!!  I'm a GENIUS from HARVARD!!
X-Attribution:  Tom
Reply-To: tromey@cygnus.com
From: Tom Tromey <tromey@cygnus.com>
Date: 15 Jan 1998 10:28:02 -0700
Message-ID: <m1k9c1d4v1.fsf@creche.cygnus.com>
X-Mailer: Red Gnus v0.34/Emacs 19.34
Content-Type: text
X-UIDL: ea5e2e46c228fd67b43709551a178a09
Status: RO
Xref: creche.cygnus.com mail.cpio:75
Lines: 54
X-Gnus-Newsgroup: mail.cpio:75   Thu Jan 15 11:10:42 1998


Tom
------- Start of forwarded message -------
Message-ID: <34BD3CA3.33A9EB1A@odn.de>
Date: Wed, 14 Jan 1998 23:30:59 +0100
From: hknobloch@odn.de (Horst Knobloch)
Organization: test organization
Subject: cpio 2.4.2 (error and enhancement)
Newsgroups: gnu.utils.bug

Hi,

I want to thank you for writting cpio and making it freeware! It works
fine, but nevertheless I think I've found an error in cpio 2.4.2, 
because the last command line below, crashes cpio with a segmentation 
violation:

> find . -print | cpio -o --format ustar -F test.tar
> cpio -di -F /tmp/test.cpio  --no-absolute-filenames

The reason is that in the file tar.c the functions stash_tar_linkname()
and stash_tar_filename() returning a pointer into a static defined
buffer. This pointer is then freed in copyin.c.

In short:
Extracting files from tar or ustar archives with no absolute filenames 
crashes cpio.


Quick File Access For cpio 2.4.2

Is there any interest in quick file access for streamers? Because I've
already added this to cpio 2.4.2. It works pretty well (and fast) with
my WangDAT DX3400. :-) I've introduced QFA support without much changes 
to the original cpio code. In copy-out mode I generate a file with
location information. This file is then used in copy-in mode to position
the tape with the seek command. If the tape does not support the seek
command, cpio could be used in the 'normal' way.
I have to fix some minor problems but then the qfa support could be
beta-tested. 

If there is interest for QFA, you could publish the enhanced version 
under the terms of the GPL. Please send me an email what you think 
about this.


Bye, Horst

--
Horst Knobloch
hknobloch@odn.de (private)
hknobloch@lucent.com (office)
------- End of forwarded message -------


From mag@sysgo.de Sun May 17 23:50:41 1998
X-From-Line: nobody Mon Jan 26 08:59:25 1998
Received: from sysgo.de ([194.122.144.127])
	by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id DAA08245
	for <tromey@cygnus.com>; Mon, 26 Jan 1998 03:16:05 -0800 (PST)
Received: (from mail@localhost)
	by sysgo.de (8.8.8/8.8.8) id MAA11551
	for <tromey@cygnus.com>; Mon, 26 Jan 1998 12:16:02 +0100
Received: from unknown(172.17.3.10) by balu.sysgo.de via smap (V1.3)
	id sma011549; Mon Jan 26 12:15:33 1998
X-Authentication-Warning: balu.sysgo.de: mail set sender to <mag@sysgo.de> using -f
Date: Mon, 26 Jan 1998 12:15:52 +0100
From: Marius Groeger <mag@sysgo.de>
Sender: mag@mag.devdep.sysgo.de
To: tromey@cygnus.com
Subject: Re: Porting cpio 2.4.2 to LynxOS
In-Reply-To: <m1u3asf5hu.fsf@creche.cygnus.com>
Message-ID: <Pine.BSD.3.96.980126121304.86D-100000@mag.devdep.sysgo.de>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-UIDL: 0fdaa6a29f36ccb8b774662f32fc0ba8
Status: RO
Lines: 24
Xref: creche.cygnus.com mail.gnits:2563 mail.cpio:77
X-Gnus-Newsgroup: mail.gnits:2563   Mon Jan 26 08:59:25 1998
X-Gnus-Newsgroup: mail.cpio:77   Mon Jan 26 08:59:25 1998

Tom,

On 25 Jan 1998, Tom Tromey wrote:

> Marius> I've ported cpio 2.4.2 to LynxOS 2.5.0, a commercial real-time
> Marius> UNIX. The only thing that didn't work straight away was
> 
> Thanks, I'll add this patch.

Thank you.
 
> Would you like to be kept informed of cpio releases?  There hasn't
> been one in a long while, but hopefully I'll get a chance to do one
> sometime.

Well, never mind, but no. I don't mean to be rude but I was porting cpio
only because Linux rpm needs it... Anyway, I'm monitoring prep.ai.mit.edu
regularly so I'm sure I'll notice should you come up with an update.

Thanks anyway,

--Marius



From tromey@cygnus.com Sun May 17 23:50:42 1998
X-From-Line: nobody Sun Jan 25 19:42:53 1998
Received: from creche.cygnus.com (creche.cygnus.com [192.203.188.26])
	by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id QAA23388
	for <tromey@cygnus.com>; Sun, 25 Jan 1998 16:24:09 -0800 (PST)
Received: (from tromey@localhost) by creche.cygnus.com (8.7.6/8.7.3) id RAA09691; Sun, 25 Jan 1998 17:23:15 -0700
To: tromey@cygnus.com
Subject: [gnu.utils.bug] Porting cpio 2.4.2 to LynxOS
X-Zippy:  Everywhere I look I see NEGATIVITY and ASPHALT...
X-Attribution:  Tom
Reply-To: tromey@cygnus.com
From: Tom Tromey <tromey@cygnus.com>
Date: 25 Jan 1998 17:23:15 -0700
Message-ID: <m1soqcf5ho.fsf@creche.cygnus.com>
X-Mailer: Red Gnus v0.34/Emacs 19.34
Content-Type: text
X-UIDL: 60a144337daf01e91aa352e87a04356c
Status: O
Xref: creche.cygnus.com mail.cpio:78
Lines: 43
X-Gnus-Newsgroup: mail.cpio:78   Mon Jan 26 12:51:45 1998


Tom
------- Start of forwarded message -------
Date: Thu, 22 Jan 1998 18:50:39 +0100
From: mag@sysgo.de (Marius Groeger)
Subject: Porting cpio 2.4.2 to LynxOS
Message-ID: <Pine.BSD.3.96.980122184812.14A-100000@mag.devdep.sysgo.de>
Newsgroups: gnu.utils.bug

Dear cpio maintainers,

I've ported cpio 2.4.2 to LynxOS 2.5.0, a commercial real-time UNIX. The
only thing that didn't work straight away was locating rsh. On LynxOS, it
sits plainly in /bin/rsh, which wasn't searched! :-)

To fix this, apply the following diff -u patch:

--- configure.in.org    Thu Jan 22 18:46:00 1998
+++ configure.in        Thu Jan 22 18:46:20 1998
@@ -20,8 +20,8 @@
 #include <sys/socket.h>], PROGS="$PROGS rmt")])

 AC_CHECKING(for remote shell)
-if test -f /usr/ucb/rsh || test -f /usr/bin/remsh || test -f /usr/bin/rsh ||
-  test -f /usr/bsd/rsh || test -f /usr/bin/nsh; then
+if test -f /bin/rsh || test -f /usr/ucb/rsh || test -f /usr/bin/remsh ||
+  test -f /usr/bin/rsh || test -f /usr/bsd/rsh || test -f /usr/bin/nsh; then
   RTAPELIB=rtapelib.o
 else
   AC_CHECK_HEADER(netdb.h, AC_DEFINE(HAVE_NETDB_H) RTAPELIB=rtapelib.o,

Thanks,

--Marius

-------------------------------------------------------------------------------
Marius Groeger <mgroeger@sysgo.de>               SYSGO Real-Time Solutions GmbH
Software Engineering                                      Carl-Zeiss-Strasse 41
Phone: +49-6131-9138-0                       D-55129 Mainz-Hechtsheim (Germany)
FAX:   +49-6131-9138-10                                    http://www.sysgo.de/

------- End of forwarded message -------


From drepper@ipd.info.uni-karlsruhe.de Sun May 17 23:50:42 1998
X-From-Line: nobody Wed Jan 28 10:31:16 1998
Received: from ilk.de (mail.ilk.de [194.121.104.8])
	by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id IAA01367
	for <tromey@cygnus.com>; Wed, 28 Jan 1998 08:51:53 -0800 (PST)
Received: from sl-kb05.rz.uni-karlsruhe.de (drepper@mpool09.ka.ilk.de [194.121.104.138])
	by ilk.de (8.8.5/8.8.5) with ESMTP id RAA22943
	for <tromey@cygnus.com>; Wed, 28 Jan 1998 17:51:49 +0100
Received: (from drepper@localhost) by sl-kb05.rz.uni-karlsruhe.de (8.8.8/8.7.5/ud-960406) id RAA08965; Wed, 28 Jan 1998 17:51:35 +0100
To: tromey@cygnus.com (Tom Tromey)
Subject: cpio.h
Reply-To: drepper@ipd.info.uni-karlsruhe.de (Ulrich Drepper)
X-fingerprint: BE 3B 21 04 BC 77 AC F0  61 92 E4 CB AC DD B9 5A
Mime-Version: 1.0 (generated by tm-edit 7.106)
From: Ulrich Drepper <drepper@ipd.info.uni-karlsruhe.de>
Date: 28 Jan 1998 17:51:35 +0100
Message-ID: <x7pvlc5yp4.fsf@myware.rz.uni-karlsruhe.de>
X-Mailer: Gnus v5.5/XEmacs 20.3 - "Vatican City"
Content-Type: text/plain; charset=US-ASCII
X-UIDL: fe991cc3c28ec07008f4ae58fb86d65d
Status: RO
Lines: 92
Xref: creche.cygnus.com mail.gnits:2580 mail.cpio:79
X-Gnus-Newsgroup: mail.gnits:2580   Wed Jan 28 10:31:16 1998
X-Gnus-Newsgroup: mail.cpio:79   Wed Jan 28 10:31:16 1998

Hi Tom,

I've changed the cpio.h file a bit and added it to glibc (necessary
because of POSIX).  The change is minimal, a macro MAGIC must be
defined to the string "070707".  I append below my version.  Perhaps
we can synchronize so that only the copyright is different.

Thanks,

-- Uli
---------------.      drepper at gnu.org  ,-.   Rubensstrasse 5
Ulrich Drepper  \    ,-------------------'   \  76149 Karlsruhe/Germany
Cygnus Solutions `--' drepper at cygnus.com   `------------------------

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/* Extended cpio format from POSIX.1.
   This file is part of the GNU C Library.
   Copyright (C) 1992, 1998 Free Software Foundation, Inc.

   NOTE: The canonical source of this file is maintained with the GNU cpio.
   Bugs can be reported to bug-glibc@gnu.org.

   The GNU C Library is free software; you can redistribute it and/or
   modify it under the terms of the GNU Library General Public License as
   published by the Free Software Foundation; either version 2 of the
   License, or (at your option) any later version.

   The GNU C Library is distributed in the hope that it will be useful,
   but WITHOUT ANY WARRANTY; without even the implied warranty of
   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
   Library General Public License for more details.

   You should have received a copy of the GNU Library General Public
   License along with the GNU C Library; see the file COPYING.LIB.  If not,
   write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330,
   Boston, MA 02111-1307, USA.  */

#ifndef _CPIO_H
#define _CPIO_H 1

/* A cpio archive consists of a sequence of files.
   Each file has a 76 byte header,
   a variable length, NUL terminated filename,
   and variable length file data.
   A header for a filename "TRAILER!!!" indicates the end of the archive.  */

/* All the fields in the header are ISO 646 (approximately ASCII) strings
   of octal numbers, left padded, not NUL terminated.

   Field Name	Length in Bytes	Notes
   c_magic	6		must be "070707"
   c_dev	6
   c_ino	6
   c_mode	6		see below for value
   c_uid	6
   c_gid	6
   c_nlink	6
   c_rdev	6		only valid for chr and blk special files
   c_mtime	11
   c_namesize	6		count includes terminating NUL in pathname
   c_filesize	11		must be 0 for FIFOs and directories  */

/* Value for the field `c_magic'.  */
#define MAGIC	"070707"

/* Values for c_mode, OR'd together: */

#define C_IRUSR		000400
#define C_IWUSR		000200
#define C_IXUSR		000100
#define C_IRGRP		000040
#define C_IWGRP		000020
#define C_IXGRP		000010
#define C_IROTH		000004
#define C_IWOTH		000002
#define C_IXOTH		000001

#define C_ISUID		004000
#define C_ISGID		002000
#define C_ISVTX		001000

#define C_ISBLK		060000
#define C_ISCHR		020000
#define C_ISDIR		040000
#define C_ISFIFO	010000
#define C_ISSOCK	0140000
#define C_ISLNK		0120000
#define C_ISCTG		0110000
#define C_ISREG		0100000

#endif /* cpio.h */


From drepper@ipd.info.uni-karlsruhe.de Sun May 17 23:50:43 1998
X-From-Line: nobody Thu Jan 29 15:31:02 1998
Received: from ilk.de (mail.ilk.de [194.121.104.8])
	by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id OAA05247
	for <tromey@cygnus.com>; Thu, 29 Jan 1998 14:17:17 -0800 (PST)
Received: from sl-kb05.rz.uni-karlsruhe.de (drepper@mpool05.ka.ilk.de [194.121.104.134])
	by ilk.de (8.8.5/8.8.5) with ESMTP id XAA17306
	for <tromey@cygnus.com>; Thu, 29 Jan 1998 23:17:12 +0100
Received: (from drepper@localhost) by sl-kb05.rz.uni-karlsruhe.de (8.8.8/8.7.5/ud-960406) id XAA24399; Thu, 29 Jan 1998 23:16:48 +0100
To: tromey@cygnus.com
Subject: Re: cpio.h
References: <x7pvlc5yp4.fsf@myware.rz.uni-karlsruhe.de> <m1d8hbx7r3.fsf@creche.cygnus.com>
Reply-To: drepper@ipd.info.uni-karlsruhe.de (Ulrich Drepper)
X-fingerprint: BE 3B 21 04 BC 77 AC F0  61 92 E4 CB AC DD B9 5A
Mime-Version: 1.0 (generated by tm-edit 7.106)
From: Ulrich Drepper <drepper@ipd.info.uni-karlsruhe.de>
Date: 29 Jan 1998 23:16:47 +0100
In-Reply-To: Tom Tromey's message of "29 Jan 1998 14:58:24 -0700"
Message-ID: <x7d8hb3oz4.fsf@myware.rz.uni-karlsruhe.de>
X-Mailer: Gnus v5.5/XEmacs 20.3 - "Vatican City"
Content-Type: text/plain; charset=US-ASCII
X-UIDL: a7ac743eb31dbc88a722f391eeef9c23
Status: RO
Lines: 34
Xref: creche.cygnus.com mail.gnits:2585 mail.cpio:80
X-Gnus-Newsgroup: mail.gnits:2585   Thu Jan 29 15:31:02 1998
X-Gnus-Newsgroup: mail.cpio:80   Thu Jan 29 15:31:02 1998

Tom Tromey <tromey@creche.cygnus.com> writes:

> Sounds good to me.
> I'll set things up to download the new cpio.h from wherever you put
> it.  I assume somewhere on the FSF machines?

Best is on egcs.cygnus.com.  I don't know whether you have access to
this machine (it's outside the firewall).  This is where I now keep
the main CVS archive but hopefully soon the file will also be
available at

	~drepper/libc/posix/cpio.h

on any FSF machine.

> I really should do a cpio release.  As if I can find the time...

Always the same story.  I also have to make a gettext release if I
only could find the time...  Hopefully after the moving.

> Do you already have a way to change the copyright, e.g. for libit?

I'd suggest you just keep the file in the format you use and simply
add the line I added.  If you want me to have the master copy of the
file in glibc just say a work.  I could then add the file to those
files which get automatically copied on the FSF for use in GNU
packages.  This copying includes an copyright change.  These copied
files are what people normally use in their GNU packages.

-- Uli
---------------.      drepper at gnu.org  ,-.   Rubensstrasse 5
Ulrich Drepper  \    ,-------------------'   \  76149 Karlsruhe/Germany
Cygnus Solutions `--' drepper at cygnus.com   `------------------------


From tromey@cygnus.com Sun May 17 23:50:43 1998
X-From-Line: nobody Fri Feb  6 18:18:33 1998
Received: from creche.cygnus.com (creche.cygnus.com [192.203.188.26])
	by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id QAA00566
	for <tromey@cygnus.com>; Fri, 6 Feb 1998 16:27:36 -0800 (PST)
Received: (from tromey@localhost) by creche.cygnus.com (8.7.6/8.7.3) id RAA18059; Fri, 6 Feb 1998 17:27:00 -0700
To: tromey@cygnus.com
Subject: [gnu.utils.bug] gnu cpio (mt actually)
X-Zippy:  I wonder if I could ever get started in the credit world?
X-Attribution:  Tom
Reply-To: tromey@cygnus.com
From: Tom Tromey <tromey@cygnus.com>
Date: 06 Feb 1998 17:27:00 -0700
Message-ID: <m1sopwtg2z.fsf@creche.cygnus.com>
X-Mailer: Red Gnus v0.34/Emacs 19.34
Content-Type: text
X-UIDL: 099b4123ed1ece195932d272a5c3b56f
Status: RO
Lines: 123
Xref: creche.cygnus.com mail.cygnus:10283 mail.gnits:2616 mail.cpio:81
X-Gnus-Newsgroup: mail.gnits:2616   Fri Feb  6 18:18:33 1998
X-Gnus-Newsgroup: mail.cpio:81   Fri Feb  6 18:18:33 1998


Tom
------- Start of forwarded message -------
From: fish@daacdev1.gsfc.nasa.gov ("John R. Vanderpool")
Message-ID: <199802052349.SAA04239@daacdev1.gsfc.nasa.gov>
Subject: gnu cpio (mt actually)
Date: Thu, 5 Feb 1998 18:49:56 -0500
Organization: NASA/GSFC
Newsgroups: gnu.utils.bug

hi, i grabbed cpio from gnu cuz i needed a non-brain-dead "mt" for dec osf
v4.0 (it does not support remote magtape) and i found some more problems
(i'm sure the whole thing is/was a huge headache for you - open systems they
ain't!)

anyway, first one is a little simple thing i fixed wrt the -V arg, the
real reason i was  hacking it was that unload across rmt did not work to
sgi - a little look at the source code on both sides (osf client and sgi
server, and also a peak at hpux's mtio.h) revealed that mt ops 0-7 (weof to
nop) are the same (i guess from the original bsd code or something?) in all
three but diverge quickly there after (9 and up)

offline on sgi doesn't unload (don't think it does on dec either) but
since the mt code for unload is diff between the two it got even more
complicated (had to add a special unloadsgi & unloaddec to remotely do 
unloads on thme because of this)

also ifdef'ed in support for any box that has MTUNLOAD defined for local
unloads - wish i could have ifdef'ed the remote ones too but there is no
way to know what type of box a remote mtop will be going to at build time

i also noticed that even when succesful all mt calls if remote call error()
must return non-zero even on success or something

so consider these changes for the distrib - let me know what ya think!?
i did not update the manpage but will if you deem my mods worthy...

			fish


*** mt.c.orig	Wed Nov 22 16:31:49 1995
--- mt.c	Thu Feb  5 18:42:02 1998
***************
*** 16,21 ****
--- 16,23 ----
     Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA  02111-1307, USA
     */
  
+ /*  5-feb-1998 jrv remove optarg required (colon) for -V option in getopt	*/
+ /*  5-feb-1998 jrv add unload and unloadsgi and unloaddec options		*/
  
  /* If -f is not given, the environment variable TAPE is used;
     if that is not set, a default device defined in sys/mtio.h is used.
***************
*** 46,51 ****
--- 48,56 ----
     rewind	Rewind the tape.
     offline, rewoffl
  		Rewind the tape and, if applicable, unload the tape.
+    unload	Unload the tape (not supported on all systems, see offline)
+    unloadsgi	Unload the tape on a remote SGI/IRIX system
+    unloaddec	Unload the tape on a remote DEC/OSF system
     status	Print status information about the tape unit.
     retension	Rewind the tape, then wind it to the end of the reel,
  		then rewind it again.
***************
*** 62,67 ****
--- 67,74 ----
  #include <sys/io/trioctl.h>
  #endif
  #include <sys/mtio.h>
+ #define MTUNLOADSGI 13     /* unload tape from remote SGI/IRIX drive */
+ #define MTUNLOADDEC 0x17   /* unload tape from remote DEC/OSF drive */
  #endif
  #include <sys/file.h>
  #include <fcntl.h>
***************
*** 121,126 ****
--- 128,138 ----
  #ifdef MTSEEK
    "seek",
  #endif
+ #ifdef MTUNLOAD
+   "unload",
+ #endif
+   "unloadsgi",
+   "unloaddec",
    NULL
  };
  
***************
*** 148,153 ****
--- 160,170 ----
  #ifdef MTSEEK
    MTSEEK,
  #endif
+ #ifdef MTUNLOAD
+   MTUNLOAD,
+ #endif
+   MTUNLOADSGI,
+   MTUNLOADDEC,
    0
  };
  
***************
*** 183,189 ****
    tapedev = NULL;
    count = 1;
  
!   while ((i = getopt_long (argc, argv, "f:t:V:H", longopts, (int *) 0)) != -1)
      {
        switch (i)
  	{
--- 200,206 ----
    tapedev = NULL;
    count = 1;
  
!   while ((i = getopt_long (argc, argv, "f:t:VH", longopts, (int *) 0)) != -1)
      {
        switch (i)
  	{
------- End of forwarded message -------


From tromey@cygnus.com Sun May 17 23:50:44 1998
X-From-Line: nobody Thu Feb 12 14:22:35 1998
Received: from creche.cygnus.com (creche.cygnus.com [192.203.188.26])
	by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id LAA06616
	for <tromey@cygnus.com>; Thu, 12 Feb 1998 11:33:45 -0800 (PST)
Received: (from tromey@localhost) by creche.cygnus.com (8.7.6/8.7.3) id MAA28031; Thu, 12 Feb 1998 12:32:09 -0700
To: tromey@cygnus.com
Subject: [gnu.utils.bug] Who to contact with mods to cpio?
X-Zippy:  This TOPS OFF my partygoing experience!  Someone I DON'T LIKE
 is talking to me about a HEART-WARMING European film..
X-Attribution:  Tom
Reply-To: tromey@cygnus.com
From: Tom Tromey <tromey@cygnus.com>
Date: 12 Feb 1998 12:32:09 -0700
Message-ID: <m167mkr552.fsf@creche.cygnus.com>
X-Mailer: Red Gnus v0.34/Emacs 19.34
Content-Type: text
X-UIDL: ce21a2327c179c1445957f7302f00bdc
Status: RO
Xref: creche.cygnus.com mail.cpio:83
Lines: 36
X-Gnus-Newsgroup: mail.cpio:83   Thu Feb 12 14:23:17 1998


Tom
------- Start of forwarded message -------
Message-ID: <199802121419.JAA05375@gnu-life>
From: jim@arizona.tor.ec.gc.ca (Jim Roberts)
Subject: Who to contact with mods to cpio?
Date: Thu, 12 Feb 1998 09:18:57 -0500
Newsgroups: gnu.utils.bug

Hello,

  A while ago I picked up a version of cpio 2.3 and made a number
  of modifications to it which I find quite useful.  They are basically
  mods to allow rapid access to all the data on a tape - particularily
  DDS which supports filemarks.
  
  I also wrote a number of scripts and such to support our store
  and extract processes - of which backup and restore is an example.

  I was wondering who to contact regarding these changes and the
  usefulness in including them in the gnucpio application.

  This was the address included in the README file of the distribution
  I got, so this is where I thought I'd start.

  Any help appreciated.

/Jim

-- 
 --------------------------------------------------------------------
  Jim Roberts
  Environment Canada, Downsview Ontario                 jim@ec.gc.ca
  Atmospheric Environment Service           jim@arizona.tor.ec.gc.ca
------- End of forwarded message -------


From jim@arizona.tor.ec.gc.ca Sun May 17 23:50:44 1998
X-From-Line: nobody Fri Feb 13 09:19:44 1998
Received: from arizona.tor.ec.gc.ca (arizona.tor.ec.gc.ca [142.97.235.191])
	by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id HAA24190
	for <tromey@cygnus.com>; Fri, 13 Feb 1998 07:00:00 -0800 (PST)
Received: by arizona.tor.ec.gc.ca
	(1.39.111.2/16.2) id AA053911961; Fri, 13 Feb 1998 09:59:21 -0500
Message-Id: <199802131500.HAA24190@cygnus.com>
From: Jim Roberts <jim@arizona.tor.ec.gc.ca>
Subject: Re: Who to contact with mods to cpio?
To: tromey@cygnus.com
Date: Fri, 13 Feb 1998 09:59:21 -0500 (EST)
In-Reply-To: <m17m70r557.fsf@creche.cygnus.com> from "Tom Tromey" at Feb 12, 98 12:32:04 pm
X-Mailer: ELM [version 2.4 PL24]
Content-Type: text
X-UIDL: 7c3f370eda94c4fef21dda65e94716a0
Status: RO
Lines: 19
Xref: creche.cygnus.com mail.gnits:2649 mail.cpio:84
X-Gnus-Newsgroup: mail.gnits:2649   Fri Feb 13 09:19:44 1998
X-Gnus-Newsgroup: mail.cpio:84   Fri Feb 13 09:19:44 1998

| 
| I'm the official GNU cpio maintainer.  I'm pretty slow about it,
| though...
| 
Is cpio 2.3 the latest release still, and would you like a 
copy of the modification which I made?

I believe I have the original release I started with as well as
what I have done to it.

/Jim


-- 
 --------------------------------------------------------------------
  Jim Roberts
  Environment Canada, Downsview Ontario                 jim@ec.gc.ca
  Atmospheric Environment Service           jim@arizona.tor.ec.gc.ca


From Fran, (Unparsable address -- Strange character \ found:
	  "_^_ois Pinard <pinard@iro.umontreal.ca>") Sun May 17 23:50:45 1998
X-From-Line: nobody Mon Feb 23 12:54:32 1998
Received: from pluton.rtsq.qc.ca (pluton.grics.qc.ca [199.84.132.10])
	by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id VAA00190
	for <tromey@cygnus.com>; Sun, 22 Feb 1998 21:25:06 -0800 (PST)
Received: by pluton.rtsq.qc.ca (8.8.8/8.8.8) with UUCP id AAA30749; Mon, 23 Feb 1998 00:27:26 -0500
Received: by icule.progiciels-bpi.ca (8.8.5/8.7.3) id AAA20461; Mon, 23 Feb 1998 00:09:16 -0500
To: jim@arizona.tor.ec.gc.ca (Jim Roberts)
Cc: Tom Tromey <tromey@cygnus.com>
Subject: Re: Who to contact with mods to cpio?
References: <199802121419.JAA05375@gnu-life>
X-Face: "b_m|CE6#'Q8fliQrwHl9K,]PA_o'*S~Dva{~b1n*)K*A(BIwQW.:LY?t4~xhYka_.LV?Qq
 `}X|71X0ea&H]9Dsk!`kxBXlG;q$mLfv_vtaHK_rHFKu]4'<*LWCyUe@ZcI6"*wB5M@[m<Ok5/cC^=
 CxDhg=TJi^o[E
X-Emacs: Emacs 20.2, MULE 3.0 (MOMIJINOGA)
MIME-Version: 1.0 (generated by SEMI MIME-Edit 0.92 - "Oyanagi")
Content-Transfer-Encoding: 8bit
From: Franois Pinard <pinard@iro.umontreal.ca>
Date: 23 Feb 1998 00:09:14 -0500
In-Reply-To: jim@arizona.tor.ec.gc.ca's message of "Thu, 12 Feb 1998 09:18:57 -0500"
Message-ID: <oq67m629hh.fsf@icule.progiciels-bpi.ca>
X-Mailer: Quassia Gnus v0.31/Emacs 20.2
Content-Type: text/plain; charset=ISO-8859-1
X-UIDL: ddb1c7d10a76c8dc30d404ba4329a1e1
Status: RO
Lines: 26
Xref: creche.cygnus.com mail.gnits:2678 mail.cpio:85
X-Gnus-Newsgroup: mail.gnits:2678   Mon Feb 23 12:54:32 1998
X-Gnus-Newsgroup: mail.cpio:85   Mon Feb 23 12:54:32 1998

jim@arizona.tor.ec.gc.ca (Jim Roberts) writes:

> Hello,

Hi, Jim.  Did I reply to you?  I intended to, but I'm not sure if I did.

>   A while ago I picked up a version of cpio 2.3 and made a number of
>   modifications to it which I find quite useful.  They are basically
>   mods to allow rapid access to all the data on a tape - particularily
>   DDS which supports filemarks.  I also wrote a number of scripts and
>   such to support our store and extract processes - of which backup and
>   restore is an example.  I was wondering who to contact regarding these
>   changes and the usefulness in including them in the gnucpio application.
>   This was the address included in the README file of the distribution
>   I got, so this is where I thought I'd start.  Any help appreciated.

The current cpio maintainer is Tom Tromey <tromey@cygnus.com>.  Cc:ed.

>   Jim Roberts
>   Environment Canada, Downsview Ontario                 jim@ec.gc.ca
>   Atmospheric Environment Service           jim@arizona.tor.ec.gc.ca

-- 
Franois Pinard                            mailto:pinard@iro.umontreal.ca
Join the free Translation Project!    http://www.iro.umontreal.ca/~pinard


From Fran, (Unparsable address -- Strange character \ found:
	  "_^_ois Pinard <pinard@iro.umontreal.ca>") Sun May 17 23:50:45 1998
X-From-Line: nobody Tue Mar 31 23:41:25 1998
Received: from pluton.rtsq.qc.ca (root@pluton.grics.qc.ca [199.84.132.10])
	by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id VAA05877
	for <tromey@cygnus.com>; Tue, 31 Mar 1998 21:34:37 -0800 (PST)
Received: by pluton.rtsq.qc.ca (8.8.8/8.8.8) with UUCP id AAA16616 for tromey@cygnus.com; Wed, 1 Apr 1998 00:29:33 -0500
Received: by icule.progiciels-bpi.ca (8.8.5/8.7.3) id XAA21275; Tue, 31 Mar 1998 23:40:37 -0500
To: tromey@cygnus.com
Subject: Re: cpio transfer
References: <m167kutc3l.fsf@creche.cygnus.com>
X-Face: "b_m|CE6#'Q8fliQrwHl9K,]PA_o'*S~Dva{~b1n*)K*A(BIwQW.:LY?t4~xhYka_.LV?Qq
 `}X|71X0ea&H]9Dsk!`kxBXlG;q$mLfv_vtaHK_rHFKu]4'<*LWCyUe@ZcI6"*wB5M@[m<Ok5/cC^=
 CxDhg=TJi^o[E
X-Emacs: Emacs 20.2, MULE 3.0 (MOMIJINOGA)
MIME-Version: 1.0 (generated by SEMI MIME-Edit 0.92 - "Oyanagi")
Content-Transfer-Encoding: 8bit
From: Franois Pinard <pinard@iro.umontreal.ca>
Date: 31 Mar 1998 23:40:35 -0500
In-Reply-To: Tom Tromey's message of "1998-03-31 21:11:42 -07:00"
Message-ID: <oqyaxqi27w.fsf@icule.progiciels-bpi.ca>
X-Mailer: Gnus v5.6.3/Emacs 20.2
Content-Type: text/plain; charset=ISO-8859-1
X-UIDL: 39cb7a59b883f29883ecda8fd9e514b5
Status: RO
Lines: 21
Xref: creche.cygnus.com mail.gnits:2872 mail.cpio:86
X-Gnus-Newsgroup: mail.gnits:2872   Tue Mar 31 23:41:25 1998
X-Gnus-Newsgroup: mail.cpio:86   Tue Mar 31 23:41:25 1998

Tom Tromey <tromey@cygnus.com> writes:

> A question about the cpio transfer: do you want just the sources?  I
> could send you my CVS repository if you'd rather.  It consists of a
> collection of RCS files.

For `tar', initially, I carefully versioned everything (as I had dozens of
versions for every file), and I do not think I used the versioning even once.
But on the other hand, I did not have diverging branches, while I suspect
that there are such things for `cpio'.  I do not know for real.

Do what you think best.  It is easy for me to check out files :-).  `cpio'
just cannot be as messy as `tar' was, anyway!  Make sure I have the latest
copy of your work files, whatever their state, and also administrative
files, like accumulated email, test suites or directories, saved notes, etc.
I'll try to clean everything out and do an initial merge with `tar'.

-- 
Franois Pinard                            mailto:pinard@iro.umontreal.ca
Join the free Translation Project!    http://www.iro.umontreal.ca/~pinard


From tromey@cygnus.com Sun May 17 23:50:46 1998
X-From-Line: nobody Thu Apr 23 12:03:28 1998
Received: from creche.cygnus.com (creche.cygnus.com [192.203.188.26])
	by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id KAA27427
	for <tromey@cygnus.com>; Thu, 23 Apr 1998 10:52:55 -0700 (PDT)
Received: (from tromey@localhost) by creche.cygnus.com (8.7.6/8.7.3) id LAA02413; Thu, 23 Apr 1998 11:52:23 -0600
Sender: tromey@cygnus.com
To: tromey@cygnus.com
Subject: [gnu.utils.bug] cpio: PowerPC fix
X-Zippy:  I demand IMPUNITY!
X-Attribution:  Tom
Reply-To: tromey@cygnus.com
From: Tom Tromey <tromey@cygnus.com>
Date: 23 Apr 1998 11:52:21 -0600
Message-ID: <m1ra2oo27e.fsf@creche.cygnus.com>
X-Mailer: Red Gnus v0.34/Emacs 19.34
Content-Type: text
X-UIDL: 6a3a8edba98f99737e962d6e6f3faa3c
Status: O
Xref: creche.cygnus.com mail.cpio:88
Lines: 28
X-Gnus-Newsgroup: mail.cpio:88   Thu Apr 23 12:04:05 1998


Tom
------- Start of forwarded message -------
From: brian@debian.org (Brian Mays)
Subject: cpio: PowerPC fix
Reply-To: brian@debian.org (Brian Mays)
Date: Thu, 23 Apr 1998 12:03:46 -0400
Message-ID: <E0ySOTS-0000bc-00@tick.virginia.edu>
Newsgroups: gnu.utils.bug

This is a patch for cpio version 2.4.2 provided by Joel Klecker
<jk@espy.org>.

Here's a patch to get cpio to compile on powerpc:

--- cpio-2.4.2/userspec.c~      Mon Sep 26 21:42:09 1994
+++ cpio-2.4.2/userspec.c       Thu Apr 23 01:18:11 1998
@@ -82,7 +82,7 @@ struct group *getgrgid ();

 #define isdigit(c) ((c) >= '0' && (c) <= '9')

-char *strdup ();
+char *strdup (const char *s);

 /* Return nonzero if STR represents an unsigned decimal integer,
    otherwise return 0. */
------- End of forwarded message -------


From tromey@cygnus.com Sun May 17 23:50:46 1998
X-From-Line: nobody Thu Apr 30 10:52:49 1998
Received: from creche.cygnus.com (creche.cygnus.com [192.203.188.26])
	by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id JAA08860
	for <tromey@cygnus.com>; Thu, 30 Apr 1998 09:48:47 -0700 (PDT)
Received: (from tromey@localhost) by creche.cygnus.com (8.7.6/8.7.3) id KAA07525; Thu, 30 Apr 1998 10:47:55 -0600
Sender: tromey@cygnus.com
To: tromey@cygnus.com
Subject: [gnu.utils.bug] suggestion for cpio
X-Zippy:  I guess you guys got BIG MUSCLES from doing too much STUDYING!
X-Attribution:  Tom
Reply-To: tromey@cygnus.com
From: Tom Tromey <tromey@cygnus.com>
Date: 30 Apr 1998 10:47:54 -0600
Message-ID: <m1ra2f8ddx.fsf@creche.cygnus.com>
X-Mailer: Red Gnus v0.34/Emacs 19.34
Content-Type: text
X-UIDL: 264adc35a96ca30a65622bec7d7c4af6
Status: RO
Xref: creche.cygnus.com mail.cpio:90
Lines: 19
X-Gnus-Newsgroup: mail.cpio:90   Thu Apr 30 11:00:07 1998


Tom
------- Start of forwarded message -------
From: "Paul H. Hargrove" <hargrove@sccm.Stanford.EDU>
Message-ID: <199804290634.XAA27553@stiefel.Stanford.EDU>
Subject: suggestion for cpio
Date: Tue, 28 Apr 1998 23:34:10 -0700
Newsgroups: gnu.utils.bug

I would like to use GNU cpio 2.4.2 in a backup script, but am somewhat
hindered by the fact that cpio almost always exits with a a status of
zero.  In particular it would be nice if using the options '-i
--only-verify-crc' would cause cpio to exit with a non-zero status if
the crc checks fail.
-- 
Paul H. Hargrove                   All material not otherwise attributed
hargrove@sccm.stanford.edu         is the opinion of the author or a typo.
------- End of forwarded message -------


From tromey@cygnus.com Sun May 17 23:50:47 1998
X-From-Line: nobody Tue May  5 18:10:21 1998
Received: from creche.cygnus.com (creche.cygnus.com [192.203.188.26])
	by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id RAA07854
	for <tromey@cygnus.com>; Tue, 5 May 1998 17:10:27 -0700 (PDT)
Received: (from tromey@localhost) by creche.cygnus.com (8.7.6/8.7.3) id SAA23242; Tue, 5 May 1998 18:09:17 -0600
Sender: tromey@cygnus.com
To: tromey@cygnus.com
Subject: [gnu.utils.bug] cpio (mt) bugs (and possible fixes).
X-Zippy:  Can I have an IMPULSE ITEM instead?
X-Attribution:  Tom
Reply-To: tromey@cygnus.com
From: Tom Tromey <tromey@cygnus.com>
Date: 05 May 1998 18:09:16 -0600
Message-ID: <m17m40xntf.fsf@creche.cygnus.com>
X-Mailer: Red Gnus v0.34/Emacs 19.34
Content-Type: text
X-UIDL: fbc6618ae379c66601956ba1db44b2d3
Xref: creche.cygnus.com mail.cpio:92
Lines: 123
X-Gnus-Newsgroup: mail.cpio:92   Tue May  5 18:11:03 1998


Tom
------- Start of forwarded message -------
Message-ID: <199805051756.NAA19584@defiant.soscorp.com>
Reply-To: jtt@soscorp.com
Subject: cpio (mt) bugs (and possible fixes).
Date: Tue, 05 May 1998 13:56:55 -0400
From: jtt@soscorp.com (James Tanis)
Newsgroups: gnu.utils.bug


Hi folks,
	We've discovered some bugs in the mt code in the cpio
distribution. Specifically it starts with all 'status' requests over rmt
faile with an exit status of 2. This error seems to be a caused by a
disagreement between the value a function returns and the way the caller
uses the value. Once that's fixed, rmt 'status' commands start to dump
core, which turns out to be (ARRRGGHH!!) due to differing struct mtget
sized on different architechtures. *That* fixed, rmt 'status' command start
to fail to close correctly. This turns to be because some broken(?) rmt
implementations return all sorts of leading junk before the return
status. This leading junk confuses mt. At any rate here are some context
diffs for you reading pleasure.

Against virgin cpio-2.4.2

Cheers,
/jtt

################################################################

===================================================================
RCS file: /home/jtt/Work/cpio-2.4.2/RCS/rtapelib.c,v
retrieving revision 1.1
diff -u -r1.1 /home/jtt/Work/cpio-2.4.2/rtapelib.c
--- /home/jtt/Work/cpio-2.4.2/rtapelib.c	1998/05/05 14:48:50	1.1
+++ /home/jtt/Work/cpio-2.4.2/rtapelib.c	1998/05/05 17:39:02
@@ -146,6 +146,7 @@
   char buffer[CMDBUFSIZE];
 
   /* Read the reply command line.  */
+  memset(buffer, (char)0, CMDBUFSIZE);
 
   for (i = 0, cp = buffer; i < CMDBUFSIZE; i++, cp++)
     {
@@ -169,8 +170,24 @@
       return -1;
     }
 
-  /* Check the return status.  */
+#define ALLOW_BROKEN_RMT
+#ifdef ALLOW_BROKEN_RMT
+  /* 
+   * Some broken(?) rmt's (eg Solaris) return leading junk 
+   * before the return string. Strip this out.
+   * XXX is this safe?
+   */
+  for (cp=buffer; cp < buffer+CMDBUFSIZE; cp++)
+    {
+      if ( isupper(*cp) )
+	break;
+      else ( *cp = ' '); /* Make leading junk compatible with normal code */
+    }
+  if ( cp == buffer+CMDBUFSIZE )
+    return -1;
+#endif /* ALLOW_BROKEN_RMT */
 
+  /* Check the return status.  */
   for (cp = buffer; *cp; cp++)
     if (*cp != ' ')
       break;
@@ -537,7 +554,14 @@
 	       ((struct mtop *) arg)->mt_count);
       if (command (fildes, buffer) == -1)
 	return -1;
-      return status (fildes);	/* Return the count.  */
+
+      /* This appears wrong (fromm the man page) */
+      /*      return status (fildes);	/* Return the count.  */
+      
+      /* 
+       * Return 0 if the status matches the count
+       */
+      return (((struct mtop *) arg)->mt_count != status (fildes));	/* Return the count.  */
 
     case MTIOCGET:
       /* Grab the status and read it directly into the structure.
@@ -548,6 +572,20 @@
 
       if (command (fildes, "S") == -1 || (rc = status (fildes)) == -1)
 	return -1;
+
+      /* 
+       * XXXX OH THIS IS TOO STUPID FOR WORDS.
+       * The size of strucg mtget *varies* between archtichectures and
+       * there is *no* synchronization here regarding sizes, we just
+       * blindly accept the amount of data our *peer* wants to send.
+       * Sigh.... So this hack at least prevents us from overwriting our
+       * bounds, but it certainly don't mean that the info we get back 
+       * will be of any practical use.
+       * *Particularly* if the data is sent between hosts of different
+       * endianess :-)
+       */
+      if ( rc > (sizeof(struct mtget)) )
+	rc = sizeof(struct mtget);
 
       for (; rc > 0; rc -= cnt, arg += cnt)
 	{
===================================================================
RCS file: RCS/mt.c,v
retrieving revision 1.1
diff -u -r1.1 mt.c
--- mt.c        1998/05/05 14:48:12     1.1
+++ mt.c        1998/05/05 17:34:59
@@ -294,6 +294,7 @@
 {
   struct mtget status;
 
+  memset(&status, (char)0, sizeof(status));
   if (rmtioctl (desc, MTIOCGET, &status))
     error (2, errno, "%s", dev);
------- End of forwarded message -------


