Re: [fuse-devel] Readlink of deleted file?

On Tue, May 24, 2011 at 2:23 PM, Han-Wen Nienhuys <ha...@gm...> wrote:

> On Tue, May 24, 2011 at 2:02 PM, Miklos Szeredi <mi...@sz...> wrote:
>
> >>>  readlink() requires a path.  By definition, deleting a file with
> >>> unlink() removes the leaf (file) part of the path from the filesystem.
> >>> I would be astonished at a filesystem that allowed readlink() after
> >>> unlink().
> >>>
> >>>  readlink() after unlink() should yield ENOENT.
> >>
> >> The question is what will happen if readlink and unlink run
> >> concurrently.  Does the VFS and/or FUSE guarantee that they are
> >> serialized, or can fuse issue a FUSE_READLINK request while a
> >> FUSE_UNLINK is still in progress?
> >
> >
> > There's no serialization between readlink and unlink.
> >
> > Either success or ENOENT is a valid result in this case.
>
> Thanks. Is unlink serialized with any other operations (maybe due to
> VFS constraints), or can any operation happen on a deleted file?
>
>
It's still possible to have other operations performed on the deleted file
if you still happen to have a process with a valid handle to that file. In
that case it's just the file name that disappears from the namespace -- the
file contents must be still around to serve requests until the last
reference to that file is dropped.

Please note that unless you're running your file system daemon with
"-ohard_remove" the file doesn't really disappear from the namespace. FUSE
will rename it to ".fuse_hidden%08x%08x" as long as there are references to
the file.

-- 
Lucas
"If you're looking for a reason I've a reason to give: pleasure, little
treasure"