Path: utzoo!attcan!uunet!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!uflorida!travis!shirono From: shirono@ssd.csd.harris.com (Roberto Shironoshita) Newsgroups: comp.protocols.nfs Subject: Re: NFS problem Message-ID: Date: 6 Nov 90 18:59:48 GMT References: <1178@appli.se> <1990Nov03.195026.1252@virtech.uucp> <1180@appli.se> Sender: news@travis.csd.harris.com Reply-To: shirono@ssd.csd.harris.com Organization: Harris Computer Systems Lines: 41 In-reply-to: niklas@appli.se's message of 4 Nov 90 09:57:10 GMT In article <1180@appli.se> niklas@appli.se (Niklas Hallqvist) writes: > 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. Chances are, all your hosts have the same size attributes (16 bits). > 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. > > [ Examples deleted ] > > 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. Someone correct me if I am wrong, but I believe the protocol prescribes 32-bit signed attributes. We saw something quite like this around here. We traced it to the client not properly sign-extending its 16-bit attributes, so it ended up sending 65535 instead of -1. We discovered the problem when one of our machines decided to use 32-bit attributes. Sanity check: how big is the uid field in an inode in Interactive 386/ix 2.0.2? If it is 32 bits, then NCR's NFS 04.00.00 needs a bugfix. -- Roberto Shironoshita || Internet: shirono@ssd.csd.harris.com Harris Corporation || Computer Systems Division || UUCP: ...!uunet!hcx1!shirono || DISCLAIMER: The opinions expressed here are my own; they in no way reflect the opinion or policies of Harris Corporation.