Bug 7988 - Space ending folder name not well transmitted
Space ending folder name not well transmitted
Status: NEW
Product: Samba 3.6
Classification: Unclassified
Component: File services
unspecified
x86 Linux
: P5 normal
: ---
Assigned To: Jeremy Allison
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-03-06 10:46 UTC by Gontcho Mbenga Emmanuel
Modified: 2011-03-08 11:30 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Gontcho Mbenga Emmanuel 2011-03-06 10:46:04 UTC
All folder that has name ending by one or more spaces got their name changed over network, so that you can't locate the real folder you are trying to browse.
e.g. : if the folder name is "Shares " (note the space at the end of the name), the computer owning the folder browse it's name as it is, but if you try to access using samba either from the owner computer or over network with another, the name will be something like "SWRFDL~3". If you open the folder, it's content don't change but it's hard to guess which folder should be open.
I experienced this bug using Ubuntu 9.04 and 10.10.
Comment 1 Volker Lendecke 2011-03-06 18:33:27 UTC
Some data points:

It works fine with unix extensions enabled.

Windows XP Explorer seems to work fine with existing directories ending in spaces. 

Notepad seems not to be able to open files ending in spaces.

Windows XP Explorer can not create files ending in spaces.

The Windows XP file server deals fine with files ending in spaces.

I'm not sure how to deal with this. Maybe we should allow the spaces even for non-mangled names.

Jeremy?

Volker
Comment 2 Jeremy Allison 2011-03-07 12:56:37 UTC
I didn't think that a name ending in a space is valid in Windows. I don't think they can be created. That's why we mangle them.

Jeremy.
Comment 3 Volker Lendecke 2011-03-07 13:06:42 UTC
I did not manage to create them via the explorer gui, but if you do a 

ren a "b "

on the smbclient command line, you end up with a file ending in a space.

Volker
Comment 4 Jeremy Allison 2011-03-07 13:27:03 UTC
So the underlying NTFS file system will allow them, but not any Windows tools. Hmmm. Problem is if we allow them to be returned to Windows, then Windows tools opens fail when people click on the name (the space is silently stripped off). I recall this is why we mangled in the first place (I'm sure there was a bug logged against that :-) - at least then people know they can't access these names from the Windows shell & tools.

Jeremy.
Comment 5 Volker Lendecke 2011-03-07 18:53:00 UTC
On Mon, Mar 07, 2011 at 01:27:04PM +0000, samba-bugs@samba.org wrote:
> So the underlying NTFS file system will allow them, but not any Windows tools.
> Hmmm. Problem is if we allow them to be returned to Windows, then Windows tools
> opens fail when people click on the name (the space is silently stripped off).
> I recall this is why we mangled in the first place (I'm sure there was a bug
> logged against that :-) - at least then people know they can't access these
> names from the Windows shell & tools.

So, what's your vote? I would rather go and be compatible
with Windows at the CIFS level.

Volker
Comment 6 Stefan Metzmacher 2011-03-08 07:55:09 UTC
Yes, we need to be compatible on the wire...
Comment 7 Jeremy Allison 2011-03-08 11:30:11 UTC
Being compatible on the wire was what caused us to add this in the first place :-).

The issue is that although it's possible to add a filename ending in space to an NTFS filesystem, for all practical purposes it's impossible (from the Windows tools). On UNIX however, it's not only possible, it's easy for someone to do (fat fingers when renaming a file in a GUI file manager will do it :-).

If we remove this, we'll get complaints on the list that people can't access files. We used to (not that often of course :-). I'm happy to remove this if you (metze) promise to respond to every "I can't get access to my file" complaint with a "have you checked if it ends in a space/tried the mangled name ?" email :-).

For filenames on UNIX containing a colon, everyone knows the limitation and understands. For files ending in a space, there's no reason that it shouldn't work, other than the supplied Windows userland tools simply (and silently) strip off the space before requesting the open. That screws us up in real-world situations with customers who just complain "it doesn't work".

We're damned if we do, damned if we don't here. Maybe add a parameter to smbd ? Or just change the default to non-mangle and live with the complaints. There's no clear 100% obvious answer here (IMHO).

Jeremy.