[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <E1IZnsm-0003vx-00@dorka.pomaz.szeredi.hu>
Date: Mon, 24 Sep 2007 15:21:52 +0200
From: Miklos Szeredi <miklos@...redi.hu>
To: matthew@....cx
CC: miklos@...redi.hu, hch@...radead.org, trond.myklebust@....uio.no,
adilger@...sterfs.com, linux-kernel@...r.kernel.org,
linux-fsdevel@...r.kernel.org
Subject: Re: [patch 1/2] VFS: new fgetattr() file operation
> On Mon, Sep 24, 2007 at 03:06:06PM +0200, Miklos Szeredi wrote:
> > A file isn't deleted while there are still links or open files
> > refering to it. So getting the attributes for a file with nlink==0 is
> > perfectly valid while the file is still open.
>
> Is it? Why not just pretend that the attributes are wiped when the file
> is deleted.
You mean "when finally unlinked"? Delete happens when the file is
closed.
> Effectively, they are, since they can't affect anything.
Sure it can. It may be open on the server as well.
> > If a network filesystem protocol can't handle operations (be it data
> > or metadata) on an unlinked file, we must do sillirenaming, so that
> > the file is not actually unlinked.
>
> Or you could call getattr right before you unlink and cache the result
> in the client.
The file can still be modified after being unlinked.
And even if we did this caching thing and modify the attributes when
the file is modified, it would not deal with access on the remote end,
and would be much more complex than the other alternatives.
Miklos
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists