Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!gem.mps.ohio-state.edu!wuarchive!psuvax1!rutgers!aramis.rutgers.edu!athos.rutgers.edu!rbthomas From: rbthomas@athos.rutgers.edu (Rick Thomas) Newsgroups: comp.os.minix Subject: Re: comments on backup program recently posted by AST Message-ID: Date: 8 Oct 89 20:43:03 GMT References: <24985@louie.udel.EDU> Organization: Rutgers Univ., New Brunswick, N.J. Lines: 51 I downloaded and installed the patches to "backup" that were recently posted by Hans-Juegen Knobloch. I have the following comments (don't say it... you knew I would... right?) 1) The "-t" option is great, but it doesn't go far enough. I will also need to add a "-p" option that preserves the file permissions (owner and group and permissions bits word) for my own usage. I realize that this will be of limited usefulness to anyone but the superuser, because it will inevitably wind up creating a directory and then giving up the ability to write in that directory!, but for doing backups as superuser, it will be invaluable. For that matter, it will be invaluable for the original intended purpose of "backup" namely reflecting changes to /dev/ram onto the root image device. 2) Neither Andy nor Hans-Juegen has been careful about dealing with file names of exactly 14 characters. They have used strncpy in a way that indicates that they do not realize that it does not add a trailing nul character if it copies exactly the maximum number of characters. This can lead to file names that are not nul terminated, and so have garbage trailing. This is easily fixed, and I will post the patches soon. Somewhat harder (so I won't do it myself -- any volunteers out there?) would be to convert the whole thing to use the directory access routines. 3) We still need a fix to "compress -c" to make it not care about the length of the output file name. Once again, this is easy to do and I will post a patch soon. 4) Somewhere in the swamps between "XBR4D75G%DDATHD21.BITNET@cunyvm.cuny.edu" and my machine, a couple of "double-or-bar"s and all of the tabs got squished out, resulting in a cdif file that required "patch -l" to apply and even then had one hunk that failed to match. The places to put double-or-bars were fairly easy to find, once I realized that was the problem. On the other hand, perhaps Hans-Juegen will re-post his patches in compressed uuencoded format. 5) Multi-floppy backups still have serious problems. This subject needs some thought before we barge in with an implementation. I will post some of my own thinking on this in another message later on. Enjoy! Rick -- Rick Thomas uucp: {ames, att, harvard}!rutgers!jove.rutgers.edu!rbthomas internet: rbthomas@JOVE.RUTGERS.EDU bitnet: rbthomas@zodiac.bitnet Phone: (201) 932-4301