On Tue, 2006-06-06 at 14:05 -0400, Peter Staubach wrote:
> On the NFS client side, there was an optimization added which attempted
> to avoid an over the wire call if the size of the file was not going to
> change. This would be great, except for the side effect of the mtime
> on the file needing to change anyway. The solution is just to issue the
> over the wire call anyway, which, as a side effect, updates the mtime and
> ctime fields.
Vetoed!
The current code gets it quite right: if someone calls open(O_TRUNC),
then may_open() calls do_truncate() with the ATTR_MTIME|ATTR_CTIME flags
set. That will cause the client to do the right thing _regardless_ of
the size optimisation.
> On the NFS server side, there was a change to the routine, inode_setattr(),
> which now relies upon the caller to set the ATTR_MTIME and ATTR_CTIME
> flags in ia_valid in addition to the ATTR_SIZE. Previously, this routine
> would force these bits on if the size of the file was not changing. Now,
> this routine relies upon the caller to specify all of the fields which need
> to be updated.
Also wrong.
This change causes the server to do entirely the wrong thing for
truncate()/ftruncate() calls: in the SuSv3 spec, a call that fails to
change the file length is supposed to leave the file entirely unchanged:
that includes mtime/ctime as well as suid/sgid bits.
Cheers,
Trond
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
