Handling deleted files which are still open on the Linux client

Handling deleted files which are still open on the Linux client

[Steve French]

[-- Attachment #1: Type: text/plain, Size: 1551 bytes --]

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

[-- Attachment #2: .0001-cifs-Change-translation-of-STATUS_DELETE_PENDING-to-.patch.swp --]
[-- Type: application/octet-stream, Size: 12288 bytes --]

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

[Pali Rohár]

Hello,

On Wednesday 09 April 2025 08:13:19 Steve French 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.

This is related only to the Windows SMB server (or other servers which
implements only the Windows behavior; not POSIX).

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

My point is that the directory entry in the STATUS_DELETE_PENDING state
is not deleted. The directory entry when is in this state it still
exists. And Windows application (or Windows SMB client) can change this
STATUS_DELETE_PENDING state to the normal state at any time. Basically
it is like transaction. After changing directory entry into the
STATUS_DELETE_PENDING you need to either "confirm" this deletion or to
"cancel" it.

The Linux SMB client does not support this "cancel" functionality but
any other clients can support it and Windows one is example.

So in my opinion I think that on Windows the directory entry in the
STATUS_DELETE_PENDING is not removed and hence I think that reporting
"ENOENT" on Linux to userspace is not correct. The entry still exists.

On POSIX/Linux there is unlink syscall which completely removes the
directory entry. This is opposite of the STATUS_DELETE_PENDING which
just puts the directory entry into some temporary / pending state.
The unlink cannot be "cancelled".

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

I think that filtering out directory entries which are in
STATUS_DELETE_PENDING from the readdir() is not a good idea. Because in
this case the readdir() on directory which has only STATUS_DELETE_PENDING
children would return empty list of entries, but the rmmdir() would fail
on it with error ENOTEMPTY. This is because entries in
STATUS_DELETE_PENDING still exists in that directory and Windows really
does not allow to remove directory which contain child entries (and it
does not matter if the child entries are in normal state or in
STATUS_DELETE_PENDING state).

So I think it would be very confusing if Linux readdir() would report
that directory is empty but rmdir() will fail with ENOTEMPTY error.
I think that this would be less accurate with POSIX behavior.

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

My other patches in that series are improving SMB client to allow
calling "stat /mnt/deleted-but-still-open-file" and fill stat buffer
without EBUSY error. Just opening a file for reading or writing would
fail with EBUSY.

On Windows and also over SMB it is possible to do "stat" also for
directory entries which are in STATUS_DELETE_PENDING.

And important is that Windows C stat() function in msvcrt.dll and UCRT
libraries is already allowing it and working fine also with files in
STATUS_DELETE_PENDING.

Note that NFS3 (client) has similar problem. Its unlink syscall is
implemented as silly-rename, it just rename file and disallow opening
it. But the directory entry still exists, other users can call "stat" on
it, just cannot open it.

So I think that returning EBUSY, which implies that the filename still
exists is a correct thing to do. Because the file really still exists.
It was not removed / unlinked from the directory yet. And hence also the
directory cannot be removed yet because it contains child entries.

Note that this whole thing is only for Windows SMB behavior, not the
Samba or other POSIX implementation where the real unlink happens.

> Any thoughts?
> 
> 
> -- 
> Thanks,
> 
> Steve

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

[Tom Talpey]

On 4/9/2025 3:51 PM, Pali Rohár wrote:
> ...
> Note that NFS3 (client) has similar problem. Its unlink syscall is
> implemented as silly-rename, it just rename file and disallow opening
> it. But the directory entry still exists, other users can call "stat" on
> it, just cannot open it.
Um, the sillyrename can certainly be seen and even reopened, removed,
or rewritten. It's only special to the client that renamed it because
some process had it open. The NFSv3 client on that machine is the only
entity that prevents opening. Another protocol from the same client,
or pretty much any other access on the server will sail right through.
It's called "silly" for a good reason.

You're correct that DOLC can be "canceled", but a) I'm not sure it's
ever really done and b) a Posix client can't even do it. So we're
talking about a two-protocol problem. Let's not go down ratholes.

My main concern with EBUSY is the fact that it's a change, and to
somehow "improve" a situation that doesn't seem like a bug. It
seems much riskier to change it than to just keep living with it.

Tom.

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

[Pali Rohár]

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