linux-kernel - Re: [PATCH v2] cifs: Change translation of STATUS_DELETE

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20241030180353.w75vgf5uxoh3sid3@pali>
Date: Wed, 30 Oct 2024 19:03:53 +0100
From: Pali Rohár <pali@...nel.org>
To: Bharath SM <bharathsm.hsk@...il.com>
Cc: Steve French <sfrench@...ba.org>, Paulo Alcantara <pc@...guebit.com>,
	Ronnie Sahlberg <ronniesahlberg@...il.com>,
	linux-cifs@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] cifs: Change translation of STATUS_DELETE_PENDING to
 -EBUSY

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