Bug 13947 - Notepad can't open files on a share with name greater than 32 bytes and with Multibyte characters
Summary: Notepad can't open files on a share with name greater than 32 bytes and with ...
Status: RESOLVED FIXED
Alias: None
Product: Samba 4.1 and newer
Classification: Unclassified
Component: File services (show other bugs)
Version: 4.3.11
Hardware: All All
: P5 normal (vote)
Target Milestone: ---
Assignee: Karolin Seeger
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-05-14 18:15 UTC by Shyam Rathi
Modified: 2021-02-11 14:24 UTC (History)
2 users (show)

See Also:


Attachments
Patch to fix the issue. (2.57 KB, application/mbox)
2019-05-14 18:15 UTC, Shyam Rathi
no flags Details
git-am fix for master. (2.94 KB, patch)
2019-05-15 23:35 UTC, Jeremy Allison
no flags Details
git-am fix for 4.10.next, 4.9.next. (3.05 KB, patch)
2019-05-16 20:35 UTC, Jeremy Allison
slow: review+
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Shyam Rathi 2019-05-14 18:15:51 UTC
Created attachment 15147 [details]
Patch to fix the issue.

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.

I've found a solution and have attached a patch with a fix.

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.
Comment 1 Shyam Rathi 2019-05-14 18:24:14 UTC
To reproduce, create a share with a name where byte 31 and 32 are not the first byte of a mutlibyte character. Using CJK characters (3 bytes each) is a possible approach. For example, creating a share with name 에이에프에스삼점오생성 and trying to open a txt file in Notepad gives 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.

Looking at wireshark capture, the following is seen as source of this issue:

GetInfo Request FS_INFO/FileFsVolumeInformation File: Rathi9\???????????
GetInfo Response, Error: STATUS_ILLEGAL_CHARACTER

Proposed solution is to truncate the label name at the end of a multibyte character before the 32nd byte.
Comment 2 Jeremy Allison 2019-05-15 23:35:49 UTC
Created attachment 15158 [details]
git-am fix for master.

Fix OK'ed by original submitter.
Comment 3 Jeremy Allison 2019-05-16 20:35:28 UTC
Created attachment 15163 [details]
git-am fix for 4.10.next, 4.9.next.

Cherry-picked from master.
Comment 4 Ralph Böhme 2019-05-27 12:25:48 UTC
Reassigning to Karolin for inclusion in 4.9 and 4.10.
Comment 5 Karolin Seeger 2019-06-04 09:35:07 UTC
Pushed to autobuild-v4-{10,9}-test.
Comment 6 Karolin Seeger 2019-06-20 09:47:04 UTC
(In reply to Karolin Seeger from comment #5)
Pushed to both branches.
Closing out bug report.

Thanks!