Comment 27 for bug 2007055
Revision history for this message
| Nicholas Neumann (aggienick02) wrote | #27 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
7020100
(Get the code!)
So I've got more investigation results. I no longer think it is the Last Access difference that is relevant, but rather differences in the SMB request pattern from the client that triggers buggy server behavior.
First, the updated results:
1. To reproduce, The file must be non-empty. The issue does not reproduce with an empty file.
2. This reproduces using Ubuntu Server 20.04.6 LTS and 22.04.3 LTS as the client, and two different Synology NAS machines, one running the latest DSM 7.1, the other running the latest DSM 7.2. A shared folder on a "Basic" single disk volume/storage pool is all that is needed.
3. This does not reproduce when the client is the latest archlinux 2024.01.01 ISO or Ubuntu Server 23.10, or with Windows 10 via command line "copy".
4. This does not reproduce when the *server* is changed to an Ubuntu 22.04.3 LTS box, even when it is running on BTRFS. This is surprising b/c Ubuntu 22.04.3 LTS and the Synology server both run Samba 4.15.13.
5. This does not reproduce when the server is TrueNAS (running 13.0-U3.1)
So now we can look at a number of network traces and see what is different. One thing sticks out. The traces are definitely "cleaner" in the archlinux and ubuntu server 23.10 cases. In Ubuntu 20 and Ubuntu 22, the packet that sets the file info has that request "wrapped' by create file/close file SMB messages. In Ubuntu 23.10 and arch, these wrapper create/close are not present in the packet that sets the file info.
While I don't think Ubuntu 20/22 are doing anything wrong, I could see the extra create file/close file messages causing the Synology server to lose track of the fact that the last operation on the file was to set the mod time, and that when the file is closed it's mod time does not need to be updated. Then when the final file close message comes in, the mod time is incorrectly updated (because the file had bytes written to it before the mod time was set).
Finally, it is worth asking *why* the traces in arch/Ubuntu23 are cleaner/different. Both of those use cifs-utils 7.0, while Ubuntu 20/22 are on 6.x . But I don't see anything in the 7.0 commits that relates to this. I may just be looking in the wrong place.