🚀 go-pugleaf

I reported this bug a while back to gnu.utils.bug, but Michael
Bushnell told me recently that postings to gnu.utils.bug might not
make it to the right place, so here it is again, just in case.

BUG REPORT:

Program: GNU tar.  Version: 1.10.  Architecture: DEC MIPS Ultrix 4.2a
Problem: I used GNU tar to copy a large filesystem (800 megabytes)
from one machine to another, like so:

     # cd /u2; gtar olcf - . | rsh fire "(cd /u2; gtar xfp -)"

I used the "-o" option because FIRE is an NFS server and does not have
a copy of the password file used on MEDIA-LAB (the source machine),
nor does it run YP; therefore, it would not know what to do with the
user names used in a new format GNU tar file.  (An NFS server doesn't
need to know user names -- only the uid's are significant.)  The files
all made it over to FIRE fine, but there were some problems with
permissions and ownership.  Every copied directory on FIRE was copied
without preserving the permissions of the directory: every directory
made by gtar on FIRE ended up in mode 777.  Furthermore, not all of
the ownership information made it through the copy.  Most of the files
now on FIRE ended up with the correct ownership, but sprinkled
throughout the filesystem in an apparently random manner were files
left owned by root.  (These files were not owned by root on
MEDIA-LAB.)

SUGGESTION:

It should be possible to have an archive store uid's rather than user
names without going into old archive format mode.  A user may want to
copy files to a system without a password file yet still gain the
advantages provided by the new archive format.

|>ouglas /\lan
   MIT Media Lab
   Systems Programming Group
   <nessus@mit.edu>