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.
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
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.
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
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.
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
Yes, we need to be compatible on the wire...
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.
looks quite like a dup of 4317, doesn't it? *** This bug has been marked as a duplicate of bug 4317 ***