[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250920133312.myidua5tqzxzs5z2@pali>
Date: Sat, 20 Sep 2025 15:33:12 +0200
From: Pali Rohár <pali@...nel.org>
To: Stefan Metzmacher <metze@...ba.org>
Cc: Steve French <sfrench@...ba.org>, Paulo Alcantara <pc@...guebit.com>,
ronnie sahlberg <ronniesahlberg@...il.com>,
Ralph Böhme <slow@...ba.org>,
linux-cifs@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 00/35] cifs: Fix SMB rmdir() and unlink() against Windows
SMB servers
On Sunday 07 September 2025 13:05:06 Pali Rohár wrote:
> On Tuesday 02 September 2025 18:30:53 Pali Rohár wrote:
> > On Tuesday 02 September 2025 17:17:14 Stefan Metzmacher wrote:
> > > Do you have network captures showing the old and new behavior
> > > that's often easier to understand than looking at patches alone.
> > >
> > > metze
> >
> > I do not have them right now, but I can run test scenario and capture
> > them, this is not problem. Test case is pretty straightforward.
>
> In attachments are network traces of both the old and new behaviors.
> In the old behavior is visible that after calling "rm object", the
> object is still in the followup "ls" output and calling "mkdir object"
> is failing, also "stat object" is failing.
> In the new behavior is visible that "rm object" is using exclusive
> removal, which fails, and then fallback to rename+deletepending which
> success. After that in the followup "ls" output the object entry is not
> there, there is only renamed ".smb<num>", and "mkdir object" pass and
> creates new directory "object".
Hello, is it enough or do you need some more data?
Powered by blists - more mailing lists