On Thu, Jun 03, 2010 at 09:32:38AM +0200, Christoph Hellwig wrote: > On Thu, Jun 03, 2010 at 09:28:12AM +0200, Christoph Hellwig wrote: > > Which means XFS behaviour for truncate while not strictly against > > Posix is at least unexpected. I'll fix it up. > > Actually I'd prefer if you could throw this into your do_truncate > patch so that filesystems don't get the clear suid request if > the file size doesn't change. Yes it should be done the same way as mtime/ctime updates are done. > That way I can just change XFS > to do everything requested but the actual size update for that case. > In fact just clearing out ATTR_SIZE in that case in do_truncate would > be nice. I thought I spotted a reason why why should not do that... I guess it is because some filesystems were choosing to do things like update ctime even when file size does not change. But if those all get stamped out, it can probably go away. > Which brings up the question: are we guaranteed to have stable > and uptodate i_size in do_truncate? I think normally we'd need > a ->getattr first to stabilize it. Good point actually. I wonder if it would be better then to pass down specific flags from the truncate code, where filesystems can call a helper to turn them into CTIME|MTIME|MODE flags when they have a stable i_size? -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
