jl42+@andrew.cmu.edu (Jay Mathew Libove) (06/14/88)
Well, having received many many items telling me to use commands like
find <names ...> -depth -print | afio .......
to backup my Xenix system, I played with it, liked it, did it, and
rebuilt my filesystem differently, and restored, no problem. Except:
it appears that directory ownership didn't come back as it had been -
files did, including all modes (I both backed up and restored as
root) but directories all came back as group:bin user:bin I think; or
maybe it was group:root user:root. Don't recall. Anyway, this caused
trouble in some spots, e.g. /usr/games/lib was writable by programs
running as gamesd before... but of course the directory became owned
by something else, and all games failed trying to write their score
files; /usr/spool/news/... had to be owned by news or the news
software couldn't process things there; I lost a few hundred
articles...
So, what did I do wrong? What funny switch(es) is(are) necessary to
get afio to write and restore directory modes too?
Thanks!
Jay Libove
Arpa: Jay.Libove@andrew.cmu.edu Bitnet: Jay.Libove@drycas.bitnet
UUCP: ...!{uunet, ucbvax, harvard}!andrew.cmu.edu!Jay.Libove
UUCP: ...!{pitt | bellcore} !darth!libove!liboveles@chinet.UUCP (Leslie Mikesell) (06/15/88)
In article <kWh1Ygy00VoD46mGwT@andrew.cmu.edu> jl42+@andrew.cmu.edu (Jay Mathew Libove) writes: >So, what did I do wrong? What funny switch(es) is(are) necessary to >get afio to write and restore directory modes too? As posted, afio gives directories the permissions of their parent when they are created because they are needed to hold a file. Since the -depth flag to find causes the directories to be written last (necessary to deal with read-only directories) you don't get the original permissions restored. A patch was posted to correct this not long after the afio posting. I can dig it up if you need it. Les Mikesell
davidsen@steinmetz.ge.com (William E. Davidsen Jr) (06/16/88)
In article <5842@chinet.UUCP> les@chinet.UUCP (Leslie Mikesell) writes: | As posted, afio gives directories the permissions of their parent when | they are created because they are needed to hold a file. Since the | -depth flag to find causes the directories to be written last (necessary | to deal with read-only directories) you don't get the original | permissions restored. A patch was posted to correct this not long | after the afio posting. I can dig it up if you need it. Please post the patch. There is a -x option, which I confidently tested and found worked... my test was wrong (sorry jay). The use of the -x flag creates the directory with the correct group, rather than default, but not user. It also won't chnage the date modified, user or group if the directory already exists. I hope the patch you have fixes this, although I admit I only use afio when there's no real cpio to be had. -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs | seismo}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
root@libove.UUCP (The Super User) (06/16/88)
In article <11269@steinmetz.ge.com>, davidsen@steinmetz.ge.com (William E. Davidsen Jr) writes: > Please post the patch. There is a -x option, which I confidently > tested and found worked... my test was wrong (sorry jay). > ...although I admit I only use afio when there's no real cpio to be had. > -- > bill davidsen (wedu@ge-crd.arpa) > {uunet | philabs | seismo}!steinmetz!crdos1!davidsen > "Stupidity, like virtue, is its own reward" -me Why do you prefer cpio to afio? My system has a cpio, but it lacks afio's ability to deal with multiple tape archives, and it has the more verbose modes, stats, and I believe is slightly more efficient (it has an "old" mode compatibility, for cpio -c, but otherwise uses its own header format). While we're at it, afio also has a couple of "protect me from myself" switches, and the ability (for people with tape drives that can really move, not floppies like me... *sigh*) to spawn another process to do the writes. -- Jay Libove Internet: libove@cs.cmu.edu libove@andrew.cmu.edu 5313 Ellsworth Avenue formtek!ditka!libove!libove@pt.cs.cmu.edu Pittsburgh, PA 15232 UUCP: cmucspt!formtek!ditka!libove!libove (412) 621-9649 cadre!pitt!darth!libove!libove
les@chinet.UUCP (Leslie Mikesell) (06/17/88)
In article <11269@steinmetz.ge.com> davidsen@crdos1.UUCP (bill davidsen) writes: > Please post the patch.... There seems to be a lot of interest in afio currently and apparently some people missed the patches that were posted for it. Here is a re-post of the patch that restores directory permissions. (There was another one dealing with wildcards in the -y and -Y flags). original patch follows.... ============== >From: mjy@sdti.UUCP (Michael J. Young) >Subject: Minor problem with afio >Date: 9 Dec 87 00:43:26 GMT >Organization: Software Development Technologies, Sudbury MA After running into some problems with cpio on my Microport system, I decided to finally give Mark Brukhartz's afio program a try. I was pleasantly surprised to find that it not only does not suffer from cpio's limitation on archive size (cpio as distributed by Microport seems to have problems on archives over about 16 megabytes), but it's a little bit faster as well. So it quickly replaced cpio as my preferred method of doing backups. However, I think I discovered a minor bug (the hard way!): When doing backups, I use the following command: find . -depth -print | afio .... (The -depth argument is recommended by Microport in their manual). This causes afio to archive directories AFTER their files, as expected. Unfortunately, when restoring such an archive, these directories are restored with the wrong owner and group, even if I use the -x flag! I had the pleasure of restoring an entire file system the other day, only to find out that all subdirectories of /usr had root,sys ownership! I first noticed it when news started dropping all incoming messages on the floor! The problem seems to be that openo() does not change the directory owner/group if the directory already exists. I made the following changes to correct the situation. I make no claims for the accuracy or completeness of my solution, but it seems to work the way I expect it to now. *** afio.c.orig Tue Dec 8 16:08:48 1987 --- afio.c Tue Dec 8 16:36:25 1987 *************** *** 1711,1716 reg int fd; reg ushort perm; ushort operm; Path *path; auto Stat osb; #ifdef S_IFLNK --- 1711,1718 ----- reg int fd; reg ushort perm; ushort operm; + ushort ouid; + ushort ogid; Path *path; auto Stat osb; #ifdef S_IFLNK *************** *** 1750,1755 linkalso(linkp, name); } perm = asb->sb_mode & (xflag ? S_IPERM : S_IPOPN); switch (asb->sb_mode & S_IFMT) { case S_IFBLK: case S_IFCHR: --- 1752,1761 ----- linkalso(linkp, name); } perm = asb->sb_mode & (xflag ? S_IPERM : S_IPOPN); + if (exists){ + ouid = osb.sb_uid; + ogid = osb.sb_gid; + } switch (asb->sb_mode & S_IFMT) { case S_IFBLK: case S_IFCHR: *************** *** 1773,1778 case S_IFDIR: if (exists) if (perm != operm && chmod(name, perm) < 0) return (warn(name, syserr())); else ; --- 1779,1787 ----- case S_IFDIR: if (exists) if (perm != operm && chmod(name, perm) < 0) + return (warn(name, syserr())); + else if (xflag && (asb->sb_uid != ouid || asb->sb_gid != ogid) && + chown(name, asb->sb_uid, asb->sb_gid) < 0) return (warn(name, syserr())); else ; --