fridman@aa.cpsc.ucalgary.ca (Robert Fridman) (06/18/91)
I am trying to tar up a directory that is in an NFS mounted file system. I get this error: tar: ERROR!! Cannot archive foo. It is of type nfs_dir. Nither the tar or nfs man pages describe this. But a copy worked. SETUP: DN4500, 10.3, nfs+patch 186, ethernet. Connected to sun4, SunOs 4.1.1. Has anyone seen this before. Thanks in advanced RF.
system@alchemy.chem.utoronto.ca (System Admin (Mike Peterson)) (06/18/91)
In article <1991Jun17.195903.20887@cpsc.ucalgary.ca> fridman@aa.cpsc.ucalgary.ca (Robert Fridman) writes: > >I am trying to tar up a directory that is in an NFS mounted >file system. >I get this error: > tar: ERROR!! Cannot archive foo. It is of type nfs_dir. You can't use tar on an NFS file system - this is documented somewhere in the NFS release notes I think. This is supposed to be fixed in the NFS release due out this fall/winter, since without this (and other improvements to Apollo NFS) you can't talk properly to foreign systems like HP 7x0s running HP-UX. You will also be able to wbak/rbak NFS files, and root will have root permissions, I'm told. -- Mike Peterson, System Administrator, U/Toronto Department of Chemistry E-mail: system@alchemy.chem.utoronto.ca Tel: (416) 978-7094 Fax: (416) 978-8775
rees@pisa.citi.umich.edu (Jim Rees) (06/18/91)
In article <1991Jun17.195903.20887@cpsc.ucalgary.ca>, fridman@aa.cpsc.ucalgary.ca (Robert Fridman) writes:
tar: ERROR!! Cannot archive foo. It is of type nfs_dir.
Whoever did this to tar should be shot. No wait, they should be forced to
use MS-DOS, then shot. Whoever did this has absolutely no concept of what
Domain/OS is all about, and clearly doesn't understand the first thing about
typed file systems. I can only hope that this was some contractor and not
an actual Apollo engineer.
But those of us who have been using Apollo systems for a while know that
tar has never worked. It's sort of a joke, but it's too bad that it has to
be at the customer's expense.
You can get a working version of tar from several different places. I
suggest either the gnu tar, or John Gilmore's PD tar, which is available by
ftp from pisa.citi.umich.edu.
The funny thing is that if they had just taken the Berkeley tar and compiled
it, instead of mucking with it, it would work just fine.tomg@hpcvlx.cv.hp.com. (Thomas J. Gilg) (06/20/91)
> tar: ERROR!! Cannot archive foo. It is of type nfs_dir. > The funny thing is that if they had just taken the Berkeley tar and compiled > it, instead of mucking with it, it would work just fine. I suspect the mucking they did was to support the "-A" option. Using -A, tar captures file type info. The flaw was that they still look at file typing without -A specified. All Apollo-isms should be ignored if -A isn't given. Thomas Gilg tomg@cv.hp.com
nazgul@alphalpha.com (Kee Hinckley) (06/20/91)
In article <523f42f3.1bc5b@pisa.citi.umich.edu> rees@citi.umich.edu (Jim Rees) writes: >The funny thing is that if they had just taken the Berkeley tar and compiled >it, instead of mucking with it, it would work just fine. Ah, but then it wouldn't preserve ACLs or ObjectIDs correctly, and tons of people were complaining about that, so support for that was put in. Clearly a mistake was made in the process - the options should have been distinct and the code separate, but apparently not. Although at least it doesn't just go and copy the NFS object and not complain! -- Alfalfa Software, Inc. | Poste: The EMail for Unix nazgul@alfalfa.com | Send Anything... Anywhere 617/646-7703 (voice/fax) | info@alfalfa.com I'm not sure which upsets me more: that people are so unwilling to accept responsibility for their own actions, or that they are so eager to regulate everyone else's.
wjw@ebh.eb.ele.tue.nl (Willem Jan Withagen) (06/20/91)
In article <101020055@hpcvlx.cv.hp.com.>, tomg@hpcvlx.cv.hp.com. (Thomas J. Gilg) writes:
=>
=> > tar: ERROR!! Cannot archive foo. It is of type nfs_dir.
=>
=> > The funny thing is that if they had just taken the Berkeley tar and compiled
=> > it, instead of mucking with it, it would work just fine.
=>
=> I suspect the mucking they did was to support the "-A" option. Using -A,
=> tar captures file type info. The flaw was that they still look at file typing
=> without -A specified. All Apollo-isms should be ignored if -A isn't given.
Well see the following STRANGE behaviour, anybody who can explain?
ebh{wjw}4: /com/ld -a /usr/sun/root
Directory "//eba/usr/sun/root":
sys type blocks current
type uid used length attr rights name
file type? 4 3803 P .cshrc
file type? 1 15 P .cshrc5
file type? 1 157 P .defaults
file type? 1 458 P .history
file type? 2 1626 P .login
file type? 1 84 P .login5
file type? 1 113 P .profile
file type? 1 70 P .profile5
file type? 1 56 P .rhosts
file type? 0 0 P .rhosts5
file type? 1 466 P .rootmenu
file type? 1 297 P .suntools
dir type? 1 88 P apollo
link awb
dir type? 2 3652 P bin
file type? 36 36244 P boot
dir type? 5 12408 P dev
dir type? 2 3828 P etc
dir type? 1 308 P install
file type? 160 152473 P kadb
dir type? 1 616 P lib
dir type? 8 88 P lost+found
dir type? 1 88 P mnt
dir type? 1 176 P stand
dir type? 1 748 P suntools
link sys
link tmp
dir type? 5 176 P tmpdev3.5
dir type? 1 88 P usr
dir type? 1 88 P usr2
file type? 544 548680 P vmunix
file type? 2 1369 P wjw_actie
32 entries, 787 blocks used.
[Note: the type mgrs ARE installed in the /sys/mgrs]
ebh{wjw}6: obty /usr/sun/root
"/usr/sun/root" object type is nfs_gate - remote from "//eba"
But then I can still go: (it takes ages, .... but it works)
ebh{wjw}7: tar cvf /tmp/barf /usr/sun/root
a /usr/sun/root/etc/fstab 1 Blocks
a /usr/sun/root/etc/exports 1 Blocks
a /usr/sun/root/etc/nd.local 1 Blocks
a /usr/sun/root/etc/dkinfo 48 Blocks
a /usr/sun/root/etc/nd 96 Blocks
a /usr/sun/root/etc/dump 176 Blocks
a /usr/sun/root/etc/rdump symbolic link to /etc/dump
a /usr/sun/root/etc/group 2 Blocks
.
.
.
Willem Jan
--
Eindhoven University of Technology DomainName: wjw@eb.ele.tue.nl
Digital Systems Group, Room EH 10.10
P.O. 513 Tel: +31-40-473401
5600 MB Eindhoven The Netherlands