Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!hellgate.utah.edu!csn!datran2!smb
From: smb@csn.org!datran2
Newsgroups: comp.sys.next
Subject: Re: FAQ -- Question #1(Next public domain software).
Message-ID: <1991Jan16.221406.1979@csn.org!datran2>
Date: 16 Jan 91 22:14:06 GMT
References: <1991Jan16.183611.1236@csn.org!datran2> <1991Jan16.192825.1412@csn.org!datran2> <1991Jan16.202825.14136@nntp-server.caltech.edu>
Organization: Data Transforms, Inc.
Lines: 23

In article <1991Jan16.202825.14136@nntp-server.caltech.edu> madler@pooh.caltech.edu (Mark Adler) writes:
>In article <1991Jan16.192825.1412@csn.org!datran2> smb@csn.org!datran2 writes:
>>by who knows what system.  If I don't use the "o" option to extract, the
>>original owners and groups are sometimes preserved.  The uid of the owner
>
>You must be using tar as a superuser.  I almost never login as root, so I
>had not observed this behavior before.  I suppose it makes good sense

In fact I have seen the behavior as a normal user.  One recent ftp tar
archive that I extracted created a subdirectory owned by a uid not defined
on my system and with no write permission for group or other.  tar then
refused to create the remainder of the files which were to be on that
subdirectory.  I had to su to remove the directory, exitted from root
and used tar xovf which created the directory with my own uid.  This
doesn't seem to occur for tar archives created from the NeXT.

Steve.

-- 
 #====#====#====#====#====#====#====#====#====#====#====#====#====#====#====#
 #  Steve Boker           #  "Badgers, we don't have no stinking badgers"   #
 #  datran2!smb@csn.org   #    -from Treasure of the Sierra Madre Zoo       #
 #====#====#====#====#====#====#====#====#====#====#====#====#====#====#====#