home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.unix.aux
- Path: sparky!uunet!sun-barr!ames!nsisrv!jagubox!jim
- From: jim@jagubox.gsfc.nasa.gov (Jim Jagielski)
- Subject: Re: tar
- Message-ID: <1095@jagubox.gsfc.nasa.gov>
- Lines: 30
- Sender: usenet@nsisrv.gsfc.nasa.gov (Usenet)
- Nntp-Posting-Host: jagubox.gsfc.nasa.gov
- Reply-To: jim@jagubox.gsfc.nasa.gov (Jim Jagielski)
- Organization: NASA/Goddard Space Flight Center
- References: <DPASSAGE.92Sep11205455@eden.CS.Berkeley.EDU>
- Date: Sat, 12 Sep 1992 13:48:59 GMT
-
- dpassage@eden.CS.Berkeley.EDU (David Paschich) writes:
-
- >Is it just me, or is tar _really way broken_ on A/UX 3.0?
-
- >I installed 3.0 on my Mac IIsi today, grabbed useful things (like the
- >UUCP fix, emacs, etc) using Zterm :), copied them over to the unix
- >filesystem, did the fcnvt thing, etc, etc...
-
- >And when I go to extract the tar files, the files tar creates get set
- >to really obnoxious foreign user id's.
-
- >This seems just really _broken_ to me. I'm not doing the extractions
- >as root, and every other unix system I've used has created the files
- >with the uid of the person doing the extraction. In fact, every other
- >unix I've used has prevented normal users from creating files owned by
- >others.
-
- The answer is that if you want the owner/group ID's to be that of
- the running process and _not_ that of the original archive, you must
- add the '-o' option... Think about it; if tar always reset the UID/GID to
- the running process, using it for system backup _and recovery_ would
- be a royal pain in the butt... after restoring files root would need to
- completely restore all the UIDs/GIDs if he/she even knew what they were...
-
- Ack!
- --
- Jim Jagielski | "This is supposed to be a happy occasion.
- jim@jagubox.gsfc.nasa.gov | Let's not bicker and argue about who
- NASA/GSFC, Code 734.4 | killed who."
- Greenbelt, MD 20771 |
-