Handling deleted files which are still open on the Linux client

[ronnie sahlberg]

On Wed, 9 Apr 2025 at 23:14, Steve French via samba-technical <
samba-technical at 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.

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.



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