[PATCH] s3:loadparm: Ensure to truncate FS Volume Label at multibyte boundary
Shyam Rathi
shyam.rathi at nutanix.com
Tue May 14 17:52:25 UTC 2019
For FS_VOLUME_INFO/FS_INFO operation, a maximum of 32 characters are
sent back. However, since Samba chops off any share name with >32
bytes at 32, it is possible that a multi-byte share name can get chopped
off between a full character. This causes the string decoding for unicode
failure which sends back NT_STATUS_ILLEGAL_CHARACTER (EILSEQ) to the client
applications.
On Windows, Notepad doesn't like it, and refuses to open a file in this
case and fails with the following error:
Invalid character. For multibyte character sets, only the leading byte is
included without the trailing byte. For Unicode character sets, include
the characters 0xFFFF and 0xFFFE.
Proposed fix:
- Find the last starting point of a multibyte codepoint if the character
at 32nd byte is a subsequent byte of a MB codepoint.
Reviewed-by: Hemanth Thummala <hemanth.thummala at nutanix.com>
Signed-off-by: Shyamsunder Rathi <shyam.rathi at nutanix.com>
Regards,
-Shyamsunder Rathi (shyam.rathi at nutanix.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-s3-loadparm-Ensure-to-truncate-FS-Volume-Label-at-mu.patch
Type: application/octet-stream
Size: 2636 bytes
Desc: 0001-s3-loadparm-Ensure-to-truncate-FS-Volume-Label-at-mu.patch
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20190514/1886b890/0001-s3-loadparm-Ensure-to-truncate-FS-Volume-Label-at-mu.obj>
More information about the samba-technical
mailing list