![]() | |||||||||||||
Messages in this thread |
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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | ||||||||||||
| Last update: 2006-06-07 07:41 [from the cache] ©2003-2008 | |||||||||||||