On Wednesday 30 October 2024 11:06:30 Bharath SM wrote: > On Mon, Oct 28, 2024 at 4:12 PM Pali Rohár <pali@xxxxxxxxxx> 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.
