Messages in this thread | | | Date | Wed, 22 Mar 2000 06:13:24 -0800 (PST) | From | David Rysdam <> | Subject | NFS client won't set GID on file create |
| |
I do not wish to offend, O Great Ones....8^)
I think I've found an...infelicity in the nfs client implementation of 2.2.5. I browsed some 2.3 code and didn't see it changed so I'm bringing it up here.
Here's the scenario: I'm running a Linux NFS client against Tru64. Tru64's file creation semantics are: -use the UID of the creating process -use the GID of the parent dir (I'm leaving out irrelevant details regarding sticky bits and so forth)
Linux's normal (i.e. non-NFS) behavior seems to be (I can't find this doc's anywhere): -use the UID of the creating process -use the GID of the creating process
However, when creating a file/dir on an NFS mount from Tru64, I got Tru64's semantics happening, not Linux's. AIX (which uses the same semantics as Linux) didn't have this "problem".
Looking at the NFS client code, I see the uid/gid getting set to -1 before being sent to the server. Glancing over the server code, it looks like we'll accept a client's UID/GID if sent and generate them otherwise. Presumably Tru64's NFS server also accepts a UID/GID from the client and that's how AIX must be implementing this.
I can definitely see why you (the NFS client) might want to say "Just do whatever the server does", but I think we'd also like to say "Do it my way".
However, I'm no NFS expert (or indeed a Linux/Unix expert)--can someone tell me if I'm way off here? If Linux is technically correct and AIX is just "nice to use" I can accept that. Otherwise however, I'd like to propose a mount flag that allows the selection of behavior. Say "server behavior" vs "client-type behavior". Or maybe it would have to be system-wide...?
__________________________________________________ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |