Re: Handling deleted files which are still open on the Linux client

["Pali Rohár" <pali@kernel.org>]

On Thursday 10 April 2025 16:18:17 ronnie sahlberg wrote:
> On Wed, 9 Apr 2025 at 23:14, Steve French via samba-technical <
> samba-technical@lists.samba.org> wrote:
> 
> > There was a suggestion (see attached patch) to change how we report
> > errors on a file which is deleted (usually by the same Linux client)
> > but still open (so "STATUS_DELETE_PENDING" if another process or
> > client tries to open it).   It can be confusing when an open file is
> > deleted to see it in "ls" output (until the file is closed and removed
> > from the namespace).   This is not an issue when using the SMB3.1.1
> > POSIX/Linux extensions but if the server were e.g. Windows it can be
> > confusing.
> >
> > Currently we return "ENOENT" which is more accurate (since the file
> > should not be displayed in directory listings, and attempts to open
> > such a file should fail in order to obey POSIX/Linux semantics), but
> > the suggestion in attached patch is to change that to "EBUSY" which
> > may imply that the file will be accessible in the future (which in
> > POSIX/Linux would not be the case so could be confusing).
> >
> > There may be better ways to handle this as well (e.g. simply filter
> > out from query dir responses any files which we know are in delete
> > pending state - since one common scenario is getting this error when
> > doing an ls of a directory which contains an open file which has been
> > deleted).
> >
> 
> This is an area where it is impossible to match semantics exactly because
> the semantics are just different.
> 
> Filtering the readdir results feels like the wrong thing to do. It is just
> trading one
> bad experience for another.
> For example, if it is filtered out  and a client tries to create a new file
> with the same
> filename,   should they see "EEXIST"?
> According to readdir() the object does not exist but if you try to create
> it you can't because EEXIST.

Exactly, this is another case where the filtering or returning ENOENT is
causing problems.

> IMHO the least bad option is probably to let the object show up in
> readdir() but
> return an error to applications that want to operate on it.
> Maybe consiider such files as having the same behaviour as a "chattr +i"
> file that has mode 0000
> and can not be opened for reading neither data not attributes.

This is what I already suggested. To return EBUSY from open(), instead
of ENOENT. Some other suggestions which I receive was to return ESTALE.

> 
> 
> >
> > One of my concerns is that with this change "stat
> > /mnt/deleted-but-still-open-file" could return EBUSY which implies the
> > filename still exists (which violates the whole point of delete in
> > POSIX), and a simpler fix is to just make sure we don't show any files
> > (e.g. in readdir) in delete pending state and make sure their dentries
> > are gone.
> >
> > Any thoughts?
> >
> >
> > --
> > Thanks,
> >
> > Steve
> >