On 7/30/25 1:29 PM, Jean-Baptiste Denis via samba wrote:> I've got a cifs mount and some operations result in data loss. I'd like > to know if this is expected or not.what it your expectation? Running this on a local filesystem gives: $ bash reproducer.sh new content In theory, the rename should fail on an SMB server as the destination of the rename has an open. Windows specs mandate that this must fail with STATUS_ACCESS_DENIED. But: Samba had a bug until very recently where it would not check this. Iirc I fixed this as part of a larger changeset that went into 4.22. https://bugzilla.samba.org/show_bug.cgi?id=15608 Cheers! -slow -- SerNet Samba Team Lead https://sernet.de/ Samba Team Member https://samba.org/ Samba Support and Dev https://samba.plus/services/ SAMBA+ packages https://samba.plus/products/samba -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 840 bytes Desc: OpenPGP digital signature URL: <http://lists.samba.org/pipermail/samba/attachments/20250730/cdb48e8f/OpenPGP_signature.sig>
Jean-Baptiste Denis
2025-Jul-30 16:11 UTC
[Samba] Sequence of actions resulting in data loss
> what it your expectation? Running this on a local filesystem gives:> > $ bash reproducer.sh > new content That's a good question. I would say that I expect the X.sh file not being deleted after the script is finished. > In theory, the rename should fail on an SMB server as the destination of the rename has an open. Windows specs mandate > that this must fail with STATUS_ACCESS_DENIED. Thank you for the clarification. > But: Samba had a bug until very recently where it would not check this. Iirc I fixed this as part of a larger changeset > that went into 4.22. > > https://bugzilla.samba.org/show_bug.cgi?id=15608 This looks very similar indeed, I'll have a further look. Thank you. Jean-Baptiste On 7/30/25 2:46 PM, Ralph Boehme wrote:> On 7/30/25 1:29 PM, Jean-Baptiste Denis via samba wrote: >> I've got a cifs mount and some operations result in data loss. I'd like to know if this is expected or not. > > what it your expectation? Running this on a local filesystem gives: > > $ bash reproducer.sh > new content > > In theory, the rename should fail on an SMB server as the destination of the rename has an open. Windows specs mandate > that this must fail with STATUS_ACCESS_DENIED. > > But: Samba had a bug until very recently where it would not check this. Iirc I fixed this as part of a larger changeset > that went into 4.22. > > https://bugzilla.samba.org/show_bug.cgi?id=15608 > > Cheers! > -slow >
Jean-Baptiste Denis
2025-Aug-01 08:04 UTC
[Samba] Sequence of actions resulting in data loss
>> But: Samba had a bug until very recently where it would not check this. Iirc I fixed this as part>> of a larger changeset that went into 4.22. >> >> https://bugzilla.samba.org/show_bug.cgi?id=15608 > > This looks very similar indeed, I'll have a further look. I just checked with a debian running 4.22: $ sudo smbd --version Version 4.22.3-Debian-4.22.3+dfsg-4 The problem still occurs (ie the file is deleted in the end, I'm not talking about the expected STATUS_ACCESS_DENIED from the specs). Is this reasonable to think that the problem could be in the cifs client code ? The fact that is occurs across a range of NAS (I think Isilon is using Likewise) and a windows server makes me think of that. I don't know what should be the correct behavior from an implementation point of view, but having a file deleted at the end seems quite brutal to me. I think this should not happen. Do you have any suggestions ? RedHat support is still focusing on the initial application that triggered this problem although I gave them the same behavior reproducer. Thank you for your help. Jean-Baptiste On 7/30/25 6:11 PM, Jean-Baptiste Denis wrote:> > what it your expectation? Running this on a local filesystem gives: > > > > $ bash reproducer.sh > > new content > > That's a good question. I would say that I expect the X.sh file not being deleted after the script is finished. > > > In theory, the rename should fail on an SMB server as the destination of the rename has an open. Windows specs mandate > > that this must fail with STATUS_ACCESS_DENIED. > > Thank you for the clarification. > > > But: Samba had a bug until very recently where it would not check this. Iirc I fixed this as part of a larger changeset > > that went into 4.22. > > > > https://bugzilla.samba.org/show_bug.cgi?id=15608 > > This looks very similar indeed, I'll have a further look. > > Thank you. > > Jean-Baptiste > > > On 7/30/25 2:46 PM, Ralph Boehme wrote: >> On 7/30/25 1:29 PM, Jean-Baptiste Denis via samba wrote: >>> I've got a cifs mount and some operations result in data loss. I'd like to know if this is expected or not. >> >> what it your expectation? Running this on a local filesystem gives: >> >> $ bash reproducer.sh >> new content >> >> In theory, the rename should fail on an SMB server as the destination of the rename has an open. Windows specs mandate >> that this must fail with STATUS_ACCESS_DENIED. >> >> But: Samba had a bug until very recently where it would not check this. Iirc I fixed this as part of a larger >> changeset that went into 4.22. >> >> https://bugzilla.samba.org/show_bug.cgi?id=15608 >> >> Cheers! >> -slow >> >