Bug#448503: NFS client problem - writing with group-access fails

[Ruediger Oberhage <ruediger@next12.theo-phys.uni-essen.de>]

Dear Maximilan Attems,

> sorry for late reply,

thanks for your reply, anyhow.

> is that fixed in newer linux images
> aka 2.6.24 or supported 2.6.25?

no, not with any of the linux-kernel-versions I tried or
checked, since then, including the 'etchnhalf' version
of 2.6.24. I didn't try 2.6.25, yet, but I don't expect the
situation to change (automatically), see below.

> thanks for feedback

I did analyze the network protocol from a working version and the
non-working one, and the one difference that I find and thus make
responsible for this is, that an 'nfs' "V3 SETATTR" call

a) has an error reported in the TCP-section
   {Checksum: 0xb43a [incorrect, should be 0x509e (maybe caused by
    checksum offloading?)]}
   in the non-working case, while it hasn't in the working one
   and
b) in the nfs-payload section it modifies under 'new_attributes'
   the size (setting it to zero) as well as
   "mtime: set to server time"
   in the non-working case,
   while it only changes the size (to zero) in the working case
   (and does not explicitely set the mtime-attribute there).

Fact is, I get an NFS3ERR_PERM answer to that client-call from the
server and am left with a zero-length file in the end!

I assume that b) is the actually culprit part. Now, I haven't read
the specs for nfs and thus can't really tell whether it is the
AIX nfs-server, that should allow that two attributes changing call,
or the Linux-Client, that shouldn't alter both attributes at once.
It workes perfectly the way it used to be and that SUN-code-derived
NFS's (IRIX, OPENSTEP, MacOS X) do. But, since Linux used to work
that way, too, a few kernel-versions in the past, even when it is
playing according to the book now, it would be nice to have an
option, so that it works with that server, too, because for us, it
is a nuissance at best and a catastrophe in the worst case.

On the other hand, it could be a real error the way it is now, and
then it should certainly be corrected.

Should you need any more information, I'll be glad to provide it
wherever I can.

Thanks for listening,
 Ruediger Oberhage