The Samba-Bugzilla – Attachment 15158 Details for
Bug 13947
Notepad can't open files on a share with name greater than 32 bytes and with Multibyte characters
Home
|
New
|
Browse
|
Search
|
[?]
|
Reports
|
Requests
|
Help
|
New Account
|
Log In
[x]
|
Forgot Password
Login:
[x]
[patch]
git-am fix for master.
0001-s3-loadparm-Ensure-to-truncate-FS-Volume-Label-at-mu.patch (text/plain), 2.94 KB, created by
Jeremy Allison
on 2019-05-15 23:35:49 UTC
(
hide
)
Description:
git-am fix for master.
Filename:
MIME Type:
Creator:
Jeremy Allison
Created:
2019-05-15 23:35:49 UTC
Size:
2.94 KB
patch
obsolete
>From cadad062f07d2c1f59cd690542dd17e1ebc37df7 Mon Sep 17 00:00:00 2001 >From: Shyamsunder Rathi <shyam.rathi@nutanix.com> >Date: Sun, 12 May 2019 23:06:17 -0700 >Subject: [PATCH] s3:loadparm: Ensure to truncate FS Volume Label at multibyte > boundary > >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. > >BUG: https://bugzilla.samba.org/show_bug.cgi?id=13947 > >Signed-off-by: Shyamsunder Rathi <shyam.rathi@nutanix.com> >Reviewed-by: Hemanth Thummala <hemanth.thummala@nutanix.com> >Reviewed-by: Jeremy Allison <jra@samba.org> >--- > source3/param/loadparm.c | 38 +++++++++++++++++++++++++++++++++++--- > 1 file changed, 35 insertions(+), 3 deletions(-) > >diff --git a/source3/param/loadparm.c b/source3/param/loadparm.c >index 5af1621fb9b..5104a3408f1 100644 >--- a/source3/param/loadparm.c >+++ b/source3/param/loadparm.c >@@ -4244,15 +4244,47 @@ const char *volume_label(TALLOC_CTX *ctx, int snum) > { > char *ret; > const char *label = lp_volume(ctx, snum); >+ size_t end = 32; >+ > if (!*label) { > label = lp_servicename(ctx, snum); > } > >- /* This returns a 33 byte guarenteed null terminated string. */ >- ret = talloc_strndup(ctx, label, 32); >+ /* >+ * Volume label can be a max of 32 bytes. Make sure to truncate >+ * it at a codepoint boundary if it's longer than 32 and contains >+ * multibyte characters. Windows insists on a volume label being >+ * a valid mb sequence, and errors out if not. >+ */ >+ if (strlen(label) > 32) { >+ /* >+ * A MB char can be a max of 5 bytes, thus >+ * we should have a valid mb character at a >+ * minimum position of (32-5) = 27. >+ */ >+ while (end >= 27) { >+ /* >+ * Check if a codepoint starting from next byte >+ * is valid. If yes, then the current byte is the >+ * end of a MB or ascii sequence and the label can >+ * be safely truncated here. If not, keep going >+ * backwards till a valid codepoint is found. >+ */ >+ size_t len = 0; >+ const char *s = &label[end]; >+ codepoint_t c = next_codepoint(s, &len); >+ if (c != INVALID_CODEPOINT) { >+ break; >+ } >+ end--; >+ } >+ } >+ >+ /* This returns a max of 33 byte guarenteed null terminated string. */ >+ ret = talloc_strndup(ctx, label, end); > if (!ret) { > return ""; >- } >+ } > return ret; > } > >-- >2.21.0.1020.gf2820cf01a-goog >
You cannot view the attachment while viewing its details because your browser does not support IFRAMEs.
View the attachment on a separate page
.
View Attachment As Raw
Actions:
View
Attachments on
bug 13947
:
15147
|
15158
|
15163