On Sat, 27 Feb 1999, Jeroen Ruigrok/Asmodai wrote: > On 27-Feb-99 sth...@nethelp.no wrote: > >> Jeroen Ruigrok/Asmodai once stated: > >> > >> => -rw-r--r-- 1 4294967294 wheel 389120 Feb 14 23:54 > >> pdksh.core.xclink > >> > >> =this is exactly what I got when I tried to compile some things over > >> NFS. > >> =The created directory and files were also like this: > >> = > >> =1 drwxr-xr-x 3 4294967294 wheel - 512 Feb 15 21:09 aout/ > >> = > >> =funny, the same value. There is something left out very fundamentally > >> =somewhere. > >> > >> Just FYI. This number is 0xFFFFFFFE in hex... A search for this number > >> through the sources does not bring anything under NFS itself, though the > >> following may give a clue: > > > > Remember that the "nobody" user is uid 65534 (0xfffe). The signed > > extension of this to 32 bits is 0xfffffffe. Maybe you're seeing uid 0 > > being translated to 65534 (due to NFS) and then sign extended. > > Could be, but that is still not correct behaviour as far as my knowledge > goes. It should not get sign extended IMHO. Am I correct in assuming this > (call to the more knowledgeable ones)?
Do you have a simple repeatable test? What OS is the server running? This kind of problem is easy to fix if I can reproduce it but I don't really have enough information. A packet trace of what happened when things went wrong would be helpful (tcpdump -vv -s300 is pretty useful). -- Doug Rabson Mail: d...@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
