jik@athena.mit.edu (Jonathan I. Kamens) (03/19/89)
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
rjg@sialis.mn.org (Robert J. Granvin) (03/20/89)
>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. Note that at least some of the problems that were described below have been corrected. Those problems will completely disappear if you apply the patches that were posted on February 13th, to this group as a matter of fact. I can probably guarantee that patches won't be posted if they were already corrected in previous patches... :-) -- Robert J. Granvin "Mueslix: A natural blend of oats, barley, National Information Services octopi, Toyotas, cement and small furry rjg@sialis.mn.org animals too slow to escape our field {amdahl,hpda}!bungia!sialis!rjg agents." --'corsair'
jik@athena.mit.edu (Jonathan I. Kamens) (03/20/89)
>Note that at least some of the problems that were described below have >been corrected. Those problems will completely disappear if you apply >the patches that were posted on February 13th, to this group as a >matter of fact. Yeah, a couple of people have written to me and pointed out that some of the patches were sent out in an official patch (some of the patches were probably the ones I sent in to the author :-). For some reason, I never saw it. My mistake or my news server's, I'll never know.... I guess I'll have to get that patch and see what it fixes. However, not only is my source disk still not recovered, but the network between me and uunet is currently down. Such is life. 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
mark@jhereg.Jhereg.MN.ORG (Mark H. Colburn) (03/20/89)
In article <9938@bloom-beacon.MIT.EDU> jik@athena.mit.edu (Jonathan I. Kamens) writes: >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 am sorry that I have not gotten back to the authors of ssome of the bug reports. I got over 200 comments to Pax. Some were bugs, some comments, others about documentation. It was difficult to respond to them all. For a number of reasons, I have been quite busy and have not gotten back to Pax. I am, however, working on it again. A number of the bugs which you had listed were fixed in a set of patches which were posted to this newsgroup in February. If you, or others, cannot find these, please let me know. I can either repost them, or mail them out to people, depending on the volume. I am currently working on a complete new release for Pax. It will have a number of organizational changes, and all of the bug reports that I got from the net (responded to or not) will be included. If you, or others, have comments or suggestions for Pax, I would love to hear them. All comments/bug fixes that I get will be ack'ed (sorry Jonathan). -- Mark H. Colburn "Look into a child's eye; Minnetech Consulting, Inc. there's no hate and there's no lie; mark@jhereg.mn.org there's no black and there's no white."