Handling deleted files which are still open on the Linux client

[Steve French]

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

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .0001-cifs-Change-translation-of-STATUS_DELETE_PENDING-to-.patch.swp
Type: application/octet-stream
Size: 12288 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20250409/72dbfeee/0001-cifs-Change-translation-of-STATUS_DELETE_PENDING-to-.patch.obj>