Bug 4317 - Folders with a white space at the end are not displayed correctly.
Summary: Folders with a white space at the end are not displayed correctly.
Status: RESOLVED DUPLICATE of bug 7001
Alias: None
Product: Samba 3.0
Classification: Unclassified
Component: File Services (show other bugs)
Version: 3.0.23d
Hardware: x86 Linux
: P3 normal
Target Milestone: none
Assignee: Samba Bugzilla Account
QA Contact: Samba QA Contact
: 7988 (view as bug list)
Depends on: 11255
  Show dependency treegraph
Reported: 2007-01-01 10:39 UTC by Simon Wenner (dead mail address)
Modified: 2021-06-28 17:50 UTC (History)
2 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Simon Wenner (dead mail address) 2007-01-01 10:39:13 UTC
Create a folder with a white space at the end inside a Samba share under Linux. Then access it over Samba and you see a wrong folder name. Example: "test " is displayed as "TFNZPF~F".
This error also occurs if you view these folders with WinXP.

OS: Debian Testing (Etch), tested with Ubuntu 6.10 and Fedora Core 6 too

Simon Wenner
Comment 1 Jeremy Allison 2007-01-01 12:50:49 UTC
Sorry, this is not a bug. Folders ending in white space are not Windows compatible names so we must mangle them, just like we have to mangle names with a ':' character. It's not possible to create such a folder on Windows (it silently truncates the whitespace at the end of the name). I'm closing this out (there have been other similar reports in the past).
Comment 2 Björn Jacke 2007-01-03 06:09:32 UTC
Jeremy: mangling is also done with linux cifs clients which negociated the cifs unix extensions. As CIFS doesn't always equal windows I would say mangling should not be done unconditionally here but only when cifs unix extensions are not used. What do you think?
Comment 3 Volker Lendecke 2007-01-03 09:49:01 UTC
Good point :-)

Comment 4 Jeremy Allison 2007-01-03 10:47:44 UTC
Correct - for a name ending in space with unix extensions it should not be mangled. I'll look into it - sorry, I thought it was being reported for Windows clients.
Comment 5 Jeremy Allison 2007-01-04 19:21:10 UTC
Ok - what version of the Linux CIFS client code is this ?

In 3.0.23d we have the following code in smbd :

/* Here is where we must switch to posix pathname processing... */
if (client_unix_cap_low & CIFS_UNIX_POSIX_PATHNAMES_CAP) {

The "mangle_change_to_posix()" turns off all mangling for filenames - at this point smbd simply doesn't know how to create mangled names anymore.

The latest CIFSFS client code does negotiate CIFS_UNIX_POSIX_PATHNAMES_CAP - do you haev the source code for the CIFSFS client you're using ?


Comment 6 Claudius Ellsel 2021-01-06 21:58:19 UTC
I know, this is very old and I am not the original reporter. But I ran into the same issue today and first feared something went wrong when copying stuff.

I have this on GNOME with a SMB share mounted through Nautilus. Other apps (FreeFileSync in my situation) see the mangled paths for instances with spaces or dots at the end of a file-/folder-name. This might be the clients fault, though. Not sure whether it negotiates CIFS Unix extensions.
Comment 7 Claudius Ellsel 2021-01-06 22:13:18 UTC
Also linking some very similar bugs here as possible duplicates:
- https://bugzilla.samba.org/show_bug.cgi?id=7001
- https://bugzilla.samba.org/show_bug.cgi?id=7988
- https://bugzilla.samba.org/show_bug.cgi?id=10491
Comment 8 Jeremy Allison 2021-01-06 22:25:27 UTC
If this is SMB2, then yes - files ending in ' ' will *always* be mangled as they are illegal names under SMB2. This will be the case until the VFS rewrite is finished and we add in the SMB2 unix extensions.
Comment 9 Björn Jacke 2021-01-07 15:26:46 UTC
*** Bug 7988 has been marked as a duplicate of this bug. ***
Comment 10 Claudius Ellsel 2021-01-08 16:22:38 UTC
(In reply to Jeremy Allison from comment #8)
Not sure what GNOME uses for that or whether cifs unix extensions are used. Nonetheless, I guess I'll just follow https://bugzilla.samba.org/show_bug.cgi?id=11255 where progress is made to cope with this problem :)
Comment 11 Björn Jacke 2021-06-28 17:50:34 UTC

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