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 return file
from delete pending state back to normal state. And therefore it 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.

Signed-off-by: Pali Rohár <pali@kernel.org>
---
 fs/smb/client/smb2maperror.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/smb/client/smb2maperror.c b/fs/smb/client/smb2maperror.c
index ac1895358908..fbc4ed038ff5 100644
--- a/fs/smb/client/smb2maperror.c
+++ b/fs/smb/client/smb2maperror.c
@@ -368,7 +368,7 @@ static const struct status_to_posix_error smb2_error_map_table[] = {
 	{STATUS_EA_CORRUPT_ERROR, -EIO, "STATUS_EA_CORRUPT_ERROR"},
 	{STATUS_FILE_LOCK_CONFLICT, -EACCES, "STATUS_FILE_LOCK_CONFLICT"},
 	{STATUS_LOCK_NOT_GRANTED, -EACCES, "STATUS_LOCK_NOT_GRANTED"},
-	{STATUS_DELETE_PENDING, -ENOENT, "STATUS_DELETE_PENDING"},
+	{STATUS_DELETE_PENDING, -EBUSY, "STATUS_DELETE_PENDING"},
 	{STATUS_CTL_FILE_NOT_SUPPORTED, -ENOSYS,
 	"STATUS_CTL_FILE_NOT_SUPPORTED"},
 	{STATUS_UNKNOWN_REVISION, -EIO, "STATUS_UNKNOWN_REVISION"},
-- 
2.20.1

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.

For SMB1, STATUS_DELETE_PENDING is translated to ERRDOS+ERRbadshare which
is then translated to -EBUSY. In the same way is STATUS_SHARING_VIOLATION
translated to -EBUSY.

Signed-off-by: Pali Rohár <pali@kernel.org>
---
Changes in v2:
* Apply change also for SMB1 code
---
 fs/smb/client/netmisc.c      | 2 +-
 fs/smb/client/smb2maperror.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/smb/client/netmisc.c b/fs/smb/client/netmisc.c
index 2a8d71221e5e..a2fb1ae14d41 100644
--- a/fs/smb/client/netmisc.c
+++ b/fs/smb/client/netmisc.c
@@ -302,7 +302,7 @@ static const struct {
 	ERRHRD, ERRgeneral, NT_STATUS_EA_CORRUPT_ERROR}, {
 	ERRDOS, ERRlock, NT_STATUS_FILE_LOCK_CONFLICT}, {
 	ERRDOS, ERRlock, NT_STATUS_LOCK_NOT_GRANTED}, {
-	ERRDOS, ERRbadfile, NT_STATUS_DELETE_PENDING}, {
+	ERRDOS, ERRbadshare, NT_STATUS_DELETE_PENDING}, {
 	ERRDOS, ERRunsup, NT_STATUS_CTL_FILE_NOT_SUPPORTED}, {
 	ERRHRD, ERRgeneral, NT_STATUS_UNKNOWN_REVISION}, {
 	ERRHRD, ERRgeneral, NT_STATUS_REVISION_MISMATCH}, {
diff --git a/fs/smb/client/smb2maperror.c b/fs/smb/client/smb2maperror.c
index b05313acf9b2..00c0bd79c074 100644
--- a/fs/smb/client/smb2maperror.c
+++ b/fs/smb/client/smb2maperror.c
@@ -368,7 +368,7 @@ static const struct status_to_posix_error smb2_error_map_table[] = {
 	{STATUS_EA_CORRUPT_ERROR, -EIO, "STATUS_EA_CORRUPT_ERROR"},
 	{STATUS_FILE_LOCK_CONFLICT, -EACCES, "STATUS_FILE_LOCK_CONFLICT"},
 	{STATUS_LOCK_NOT_GRANTED, -EACCES, "STATUS_LOCK_NOT_GRANTED"},
-	{STATUS_DELETE_PENDING, -ENOENT, "STATUS_DELETE_PENDING"},
+	{STATUS_DELETE_PENDING, -EBUSY, "STATUS_DELETE_PENDING"},
 	{STATUS_CTL_FILE_NOT_SUPPORTED, -ENOSYS,
 	"STATUS_CTL_FILE_NOT_SUPPORTED"},
 	{STATUS_UNKNOWN_REVISION, -EIO, "STATUS_UNKNOWN_REVISION"},
-- 
2.20.1

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.

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.