Re: [PATCH against 2.6.14] truncate() or ftruncate shouldn't change mtime if size doesn't change.

On Mon, 2005-10-31 at 07:51 -0500, Trond Myklebust wrote:
> This should normally be OK as far as NFS is concerned since we usually
> end up revalidating the attribute cache in the lookup() code, but you
> could imagine a networked filesystem that does not do this. I'd
> therefore prefer if such checks were made in the filesystem itself.

Actually, I'm wrong about this. ftruncate() doesn't do a
lookup/lookup_revalidate, so the current NFS code may end up using stale
attribute data.

Moving the checks to the VFS will just make that problem unfixable,
though.

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/

References:
- [PATCH against 2.6.14] truncate() or ftruncate shouldn't change mtime if size doesn't change.
  - From: NeilBrown <[email protected]>
- Re: [PATCH against 2.6.14] truncate() or ftruncate shouldn't change mtime if size doesn't change.
  - From: Trond Myklebust <[email protected]>

Prev by Date: Introduction to the Linux kernel development process
Next by Date: Make spitz compile again
Previous by thread: Re: [PATCH against 2.6.14] truncate() or ftruncate shouldn't change mtime if size doesn't change.
Next by thread: Re: [PATCH against 2.6.14] truncate() or ftruncate shouldn't change mtime if size doesn't change.
Index(es):
- Date
- Thread

[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]