Path: utzoo!utgpu!watserv1!watmath!att!att!rutgers!cs.utexas.edu!uwm.edu!rpi!uupsi!sunic!chalmers.se!appli!niklas
From: niklas@appli.se (Niklas Hallqvist)
Newsgroups: comp.protocols.nfs
Subject: Re: NFS problem
Keywords: NFS RPC attributes
Message-ID: <1180@appli.se>
Date: 4 Nov 90 09:57:10 GMT
References: <1178@appli.se> <1990Nov03.195026.1252@virtech.uucp>
Organization: Applitron Datasystem AB, GOTHENBURG, SWEDEN
Lines: 59

cpcahil@virtech.uucp (Conor P. Cahill) writes:

>In article <1178@appli.se> niklas@appli.se (Niklas Hallqvist) writes:
>>> when I try to set file attributes.  If some attributes are unspecified
>>> (e.g uid, gid or mode) they get changed anyway to -1.  I know this is
>>> mentioned in the NFS manual for 386/ix.  What I'm asking here is not

>We have had NFS running here for over a year and have not seen this problem. 
>Post a mechanism to reproduce the problem so that others can see what 
>is actually hapening.

Ok, here's an example... I'm running on NCR Tower 650 with UnixV.3
(rel. 030001) and NFS 04.00.00.  The current diretory is
residing on a machine running 386/ix 2.0.2 and NFS 2.0.0.

Example 1, Change of permissions.
$ > test1
$ ls -l test1
-rw-r--r--   1 niklas   usr            0 Nov  4  1990 test1
$ chmod 666 test1
$ ls -l test1
-rw-rw-rw-   1 65535    65535          0 Nov  4  1990 test1

Example 2, Change of owning user.
$ > test1
$ ls -l test1
-rw-r--r--   1 niklas   usr            0 Nov  4  1990 test1
$ chown root test1
$ ls -l test1
-rwxrwxrwx   1 root     usr            0 Nov  4  1990 test1*

Example 3, Change of owning group.
$ > test1
$ ls -l test1
-rw-r--r--   1 niklas   usr            0 Nov  4  1990 test1
$ chgrp uucp test1
$ ls -l test1
-rwxrwxrwx   1 niklas   uucp           0 Nov  4  1990 test1*

As you can see, when the permissions bits are changed, the owner and
group bits get set to ones.  Almost the same thing happens when you
change the owning user or group, but then only the permission bits get
replaced by one bits.  I want to enhance the fact that this only occurs
when running on the NCR and using NFS-mounted partitions from a 386/ix
node.  Not the other way around, or when a 386/ix machine replaces the
NCR in my scenario.  It just occurred to me, that it really might by
the NCR NFS being the bandit here.  The question is:  How many bits
is a NFS attribute? 16 or 32?  If it is 32, the problem might be that
the NCR just supplies a 16-bit value of -1, which in the 32-bit context
surely gets evaluated to 65535.  But if the number of bits is 16, I can't
see anything but Interactive NFS being guilty!  Comments....?  I have to
know who's responsible if I'm going to report this.

					Niklas
-- 
Niklas Hallqvist	Phone: +46-(0)31-40 75 00
Applitron Datasystem	Fax:   +46-(0)31-83 39 50
Molndalsvagen 95	Email: niklas@appli.se
S-412 63  GOTEBORG, Sweden     mcsun!sunic!chalmers!appli!niklas