AFIO and find -depth problem.

[Hibbard T. Smith JR]

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