Comment 13 for bug 2049634
Revision history for this message
| R. Diez (rdiezmail-ubuntu) wrote Re: smb1: wsize blocks of bytes followed with binary zeros on copy, destroying data | #13 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
bbfa235
(Get the code!)
For the benefit of the subscribers to this bug, who may not be following the corresponding e-mail thread in the linux-cifs mailing list:
This bug does not only affect SMB 1.0, but all SMB versions. It will probably bite you if you specify a wsize mount option with a number of bytes which is not a multiple of PAGE_SIZE (usually 4 KiB, but not always).
You can find out what the page size on your system is with command "getconf PAGE_SIZE".
You do not actually have full control of the write buffer size, as it is the result of a negotiation, so if the server happens to set a maximum that is not a multiple of PAGE_SIZE, and is lower than the maximum you requested, you will probably end up with data corruption. Fortunately, most modern servers appear to send unproblematic values, so that is why this bug was discovered only when connecting to an old SMB 1.0 server.
There is a workaround for this bug. In my case, the connection negotiated a wsize of 16580, even though the server should actually default to 16644 bytes (?). I have specified a mount option of wsize=16384, which is the next multiple of 4 KiB downwards, and performed a quick test, and it looks fine. I'll shout here again if my data gets corrupted once more.