Path: utzoo!attcan!uunet!lll-winken!ames!haven!purdue!bu-cs!bloom-beacon!athena.mit.edu!jik
From: jik@athena.mit.edu (Jonathan I. Kamens)
Newsgroups: comp.sources.bugs
Subject: PAX bugs
Summary: PAX isn't as great as it's cracked up to be
Message-ID: <9938@bloom-beacon.MIT.EDU>
Date: 19 Mar 89 09:35:37 GMT
Sender: daemon@bloom-beacon.MIT.EDU
Reply-To: jik@athena.mit.edu (Jonathan I. Kamens)
Organization: Massachusetts Institute of Technology
Lines: 82

I have sent several bug reports to the author of pax.  He responded to
the first one, but failed to respond to any after that, and has not
posted any of the patches I sent him to the network.  I've waited
about two months to see them posted, but this hasn't happened, so I no
longer feel it is necessary to wait for him to post the fixes,
especially since he no longer responds to my mail.

I can't post patches to the sources right now, because the disk my
sources are on crashed last Friday and hasn't been restored from
backup yet.  However, I can give you a list of the bugs that I found,
and I will provide patches later this week when I can get at my
sources.

1. A close() instead of a closedir() in the procedure name_next (I
   think that's the name of the procedure) causes open directories to
   build up until the process runs out of room for opening new files
   and directories.

2. When an opendir() fails in that same procedure, it checks the
   status but fails to back out properly so the procedure will
   continue to try to read from the directory that could not be
   opened, resulting in various gross horrible things such as bus
   errors and green monsters with dripping fangs coming to visit you
   in your sleep :-).

3. The man page for Pax says "Pax is capable of reading and writing
   archives which span multiple physical volumes.  Upon detecting an
   end of medium on an archive which is not yet completed, pax will
   prompt the user for the next volume of the archive and will allow
   the user to specify the location of the next volume."  However,
   when the end of a volume is reached on my machine (I'm writing to a
   floppy drive.), Pax prompts me to type go to continue or quite to
   abort.  It gives no indication that I can choose to enter another
   volume name (and doesn't accept it if I do).

4. The function create_archive does a regexp replace on each filename
   encountered, and then continues (i.e. skips the file) if the
   resulting name has length zero.  However, if the resulting name has
   length 0 it does not *closing* the file descriptor for the file.
   Fixed with the addition of three lines of code.

5. The man page for pax says the following about the -u option: "Copy
   each file only if it is newer than a pre-existing file with the
   same name.  This implies -a."  However, the code in pax.c calls
   that flag "f_unconditional" and does not at all use it in the
   manner described in the man page.  The comments don't even agree.
   I think that the stuff in the source file has to do with tar, which
   uses -u differently, but I'm not sure.

6. When the user specifies -w and then -a, as he must do when he
   wishes to append to the end of a tape, both the f_create and
   f_append flags get set.  Then, when the set of if ... else
   statements gets executed after the argument processing, f_create is
   checked *before* f_append is checked, and if f_create is true the
   archive is created from scratch no matter what the value of
   f_append.  This is obviously wrong -- the check for f_append should
   be moved before the check for f_create in the code (and don't
   forget to check for command-line arguments in the body of the
   f_append if the same way they are checked in the body of the
   f_create if.

7. When appending to the end of the archive, pax keeps reading until
   it has read the EOT marker and then writes the next archive.  This
   should immediately seem strange to you.... the next time the
   archive is read in, pax (or tar, or whatever) will *stop* at the
   EOT marker and will not proceed past it to the new file(s).

   In order to get append to work properly, it is probably necessary
   to do something similar to what tar does, which is to read past the
   EOT marker and then to go backwards until the end of the last file
   on the tape is reached so that the new file can be written directly
   over the EOT marker.  I don't see how you can do it otherwise.

I have patches to all of these problems except for the -u flag not
working and for the final problem, which can only be fixed by
changing the way pax appends to the end of an archive.  Like I said,
when I can get to my sources I will post the patches.

Jonathan Kamens			              USnail:
MIT Project Athena				410 Memorial Drive, No. 223F
jik@Athena.MIT.EDU				Cambridge, MA 02139-4318
Office: 617-253-4261			      Home: 617-225-8218