smitty@essnj1.UUCP (Hibbard T. Smith JR) (05/26/90)
We've been using AFIO (a PD cpio replacement) for backups recently. It has some functionality which cpio doesn't. It also provides a crude multi-tasking capability which makes backups run considerably faster than with cpio. Last week, for the first time, I used it to do a complete backup of my system. The command looked like: (from / and as root) "find . -depth -print|afio -ovfzb16k -c32 -s60m /dev/rmt0" I then proceeded to create all new file systems (to integrate a new disk). After the basics were reinstalled, I copied afio from a svae diskette, and restored the system thusly: (from / and as root) "afio -ivzb16k -c32 -s60m /dev/rmt0" The restore proceeded without error and after 7 tapes, I was done. I then proceeded to use the system. After a short time it became apparent that some file mode problems existed. After looking around for awhile, I realized that non-empty directories created by afio during the restore all belonged to root, or the same owner as their first existing ancestor. This usually meant that their rightful owners couldn't read/write in them. The files in the directories were fine. Examination of the afio source revealed that if the directory entry on the archive follows the first file that needs the directory, afio will create the directory when needed. It will be owned by the same user as the first available ancestor or the user running the afio. Subsequently when the real directory entry shows up on the archive, afio makes no attemp to change the owner, group, or modes of the directory he created earlier. This can be avoided (when running as root) by *not* using the -depth option to find. No workaround is available for a non super-user trying to backup and restore hierarchies for which he has no write permission. That's what -depth is for. If anyone else has run into this, I'd like to hear from you. Also, if anyone's fixed (and tested) this problem, I'd really like to see the code. It appears that it wouldn't be too difficult to fix, but the ramifictions could be enormous. (After all, you do bet your entire system on this utility.) If a (tested) fix is available, I'd much prefer that to reinventing the wheel. Thanks, in advance for any help. -- Smitty ------------------------------------------- Hibbard T. Smith JR ESSNJAY Systems Inc. uunet!hsi!essnj1!smitty