Re: [PATCH v2] cifs: Change translation of STATUS_DELETE_PENDING to -EBUSY

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

On Wednesday 30 October 2024 11:06:30 Bharath SM wrote:
> On Mon, Oct 28, 2024 at 4:12 PM Pali Rohár <pali@kernel.org> wrote:
> >
> > STATUS_DELETE_PENDING error is returned when trying to open a file which is
> > in delete pending state. Linux SMB client currently translates this error
> > to -ENOENT. So Linux application trying to open a file which still exists
> > will receive -ENOENT error. This is confusing as -ENONET means that
> > directory entry does not exist.
> >
> > File on SMB server can be in delete pending state for an indefinite long
> > period. Moreover it does not have to final state before the real deleting,
> > as any SMB client who still have opened handle to such file can revert file
> > from delete pending state back to normal state. And therefore client can
> > cancel any scheduled file removal.
> >
> > So change translation of STATUS_DELETE_PENDING error to -EBUSY. -EBUSY is
> > used also for STATUS_SHARING_VIOLATION error which is similar case, when
> > opening a file was disallowed by server due to concurrent usage.
> >
> 
> My worry is that, change in error code mapping might break some
> applications compatibility.

Do you have any specific example in mind where this can happen?

I was thinking about it and I cannot imagine how this change could break
application compatibility. I do not know how can application think that
-ENOENT error from open() or stat() syscall should be handled as file
exists. This is direct contradiction of the -ENOENT meaning.