PAX bugs
Jonathan I. Kamens
jik at athena.mit.edu
Sun Mar 19 19:35:37 AEST 1989
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 at Athena.MIT.EDU Cambridge, MA 02139-4318
Office: 617-253-4261 Home: 617-225-8218
More information about the Comp.sources.bugs
mailing list