Bug 11420 - Filenames with double quotes broken somewhere before 4.0.26
Summary: Filenames with double quotes broken somewhere before 4.0.26
Status: RESOLVED DUPLICATE of bug 12830
Alias: None
Product: Samba 4.0
Classification: Unclassified
Component: File services (show other bugs)
Version: 4.0.26
Hardware: All FreeBSD
: P5 normal (vote)
Target Milestone: ---
Assignee: Jeremy Allison
QA Contact: Samba QA Contact
Depends on:
Reported: 2015-07-29 23:38 UTC by Jan Mikkelsen
Modified: 2017-10-02 18:49 UTC (History)
1 user (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Jan Mikkelsen 2015-07-29 23:38:47 UTC
Filenames with double quotes seem to have broken sometime before 4.0.26 versions.

With standard 4.0.26 a file called say "Test” (including the double quotes, ASCII 0x22 as seen on the server side) gets mangled to an 8.3 name when presented to the client. I have tested this with OS X 10.9 OSX 10.10.4 and Windows 7 clients.

The files were originally created with Samba from one of these clients, but at this point I cannot conclusively say which Samba version worked properly last. The problem became apparent after files that were created from the client are no longer accessible using their name with double quotes and only the mangled name is available.

Changing source3/smbd/mangle_hash2.c like to not treat double quotes as a special character (patch below) make the mangling stop but causes translation on 0x22 as shown below. I don’t see where this is happening.


  touch \”XYZ\”
  ls *XYZ* | xxd

when in a share directory on the client side gives:

0000000: 2258 595a 220a                           "XYZ”.

On the server side, in the same directory, ls *XYZ* | xxd gives:

00000000: ef80 a058 595a ef80 a00a                 ...XYZ….

Files are then available on the client side with conventional 0x22 double quotes, but in the Unix filesystem the quote has been changed to the UTF-8 sequence 0xef 0x80 0xa0, which by reading is the Tibetan digit zero, 0xf20, which does not seem to be a reasonable mapping for a double quote.

This is on FreeBSD 10.2-PRERELEASE with a ZFS filesystem, with Unicode filenames enabled and enforced. This is samba 4.0.26 installed using the standard FreeBSD port.

--- source3/smbd/mangle_hash2.c.orig	2015-07-29 13:10:58.889516029 +1000
+++ source3/smbd/mangle_hash2.c	2015-07-29 13:14:11.914503055 +1000
@@ -109,7 +109,7 @@
 { "AUX", "LOCK$", "CON", "COM1", "COM2", "COM3", "COM4",
   "LPT1", "LPT2", "LPT3", "NUL", "PRN", NULL };
@@ -145,7 +145,7 @@
 			char_flags[i] |= FLAG_ASCII;
-		if (strchr("*\\/?<>|\":", i)) {
+		if (strchr("*\\/?<>|:", i)) {
 			char_flags[i] |= FLAG_ILLEGAL;
Comment 1 Jeremy Allison 2015-07-30 18:32:00 UTC
I don't think this is valid.

Names with " characters are not allowed on NTFS filesystems. See here:


for details. You can't create such names on any NTFS filesystem on Windows.

Now how did the existing names get there ? My guess is using UNIX extensions on older versions of MacOSX. Samba supports UNIX extensions with POSIX pathnames, which only disallows '/' and '\0' characters in names, and MacOSX used to use this.
Comment 2 Jan Mikkelsen 2015-07-31 07:34:25 UTC
That makes sense, thanks for investigating.

The files were created from OS X over various versions, so your suspicion about how they got there is also consistent.

We'll deal with it by removing double quotes from the names.

(In reply to Jeremy Allison from comment #1)
Comment 3 Björn Jacke 2017-10-02 18:49:53 UTC

*** This bug has been marked as a duplicate of bug 12830 ***