the "mapchars" option should also hande trailing space and trailing period I think. Currently a Linux cifs client can create those files on a Samba server but they cannot be accessed after, because they are returned mangled then. Which standard is the cifs vfs mapchars using btw? From the commit I read: +/* Windows maps these to the user defined 16 bit Unicode range since they are + reserved symbols (along with \ and /), otherwise illegal to store + in filenames in NTFS */ But I don't find any reference document for such a mapping. If the "mapchars" mapping is based on a standard it would be great if that would be mentioned in the man page and in the code. Is there any reference for the mapping, Steve? The only reference for a predefined mapping is the one for for the Services for Macintosh (mskb 117258). This one also handles the trailing period and trailing space: Macintosh ANSI Unicode ----------------------------------------------------------------------- Space (0x20) 0xF028 only if occurring as the last character of the name Period (0x2E) 0xF029 only if occurring as the last character of the name Maybe those mapping should to adopted for cifs vfs also. Or should the current mapchars be deprecated completely for the http://support.microsoft.com/en-us/kb/kbview/117258 mappings?
Fwiw, vfs_fruit lacks this too.
While testing with that, I realized, that the mapping that cifs vfs uses is actually the same like the mapping for SFM as described in MS KB 117258 (except for the trailing period and space).
Yes - cifs.ko can use two mappings depending on the mount options - the "SFU" (Services for Unix) style mapping (Microsoft Services For Unix was renamed to "SUA" in later releases) to be compatible with Windows and the SFM (Macintosh, and "Services for Mac") style mapping to allow compatibility with Apple. The later is intended to be the default for the future (for SMB3) as both Apple and Linux can use it - so can be used by vfs_fruit and cifs.ko
On 2015-04-13 at 04:55 +0000 samba-bugs@samba.org sent off: > https://bugzilla.samba.org/show_bug.cgi?id=11206 > > --- Comment #3 from Steve French <smfrench@gmail.com> --- > Yes - cifs.ko can use two mappings depending on the mount options - the "SFU" > (Services for Unix) style mapping (Microsoft Services For Unix was renamed to > "SUA" in later releases) to be compatible with Windows > SFM (Macintosh, and "Services for Mac") style mapping to allow compatibility > with Apple. it supports *both* ? The man page just says somehting about the "mapchars" parameter, no further details what kind of mapping that is and nothing about how a 2nd type of mapping can be enabled. If you point me to the details, I'd be glad to provide a man page update. Also a pointer to a web ressource, describing the SFU/SUA mapping would be great. I did not find anything about that. (sorry, actually that was slightly offpotic for this bug report) > The later is intended to be the default for the future (for SMB3) > as both Apple and Linux can use it - so can be used by vfs_fruit and cifs.ko I would not like to see a different mapping default for smb1/smb2/smb3. This is highly confusing, also a by using DFS it might happen that the same UNC path ends up on a SMB1 or on a SMB3 server. Or imagine a file server is being updated, yesterday it could just speak smb1, today it speaks SMB3 - or the other way round also. Then all the files are unaccessable suddenly by Linux cifs client. Or if unix extensions were supported before and then mappings also, you end up with same names on the server in different "encodings", the real encoding and then the new "mapping encodinf". Protocol based different defaults sound like a really bad idea to me. (sorry, actually that was slightly offpotic for this bug report again ;)
trailing dot and space seem to be legal now. see comment2 in https://bugzilla.samba.org/show_bug.cgi?id=11207
I don't know how I managed to see teh SFM mappings. IN the code and also in tests now I just see the +F000 mapping, which seem to have been the standard mapping in the SFU of very old Windows versions. Today there are no default mappings any more. In addition to that I notices that cifs VFS lacks the mapping for the quote " and it lacks mappings for 0x01-0x1f. How about switching from the current - anyway incomplete - old SFU mapping to a complete SFM mapping, so that Mac CIFS cllients and Linux CIFS clients have a chance for common view on the files? Actually I see little reason for keeping the current incomplete mapchars. I prepare a convmv version which is able to convert those sfu and sfm mappings, this makes transition easy. Steve, Jeff, what do you think?
We probably don't want to change defaults for cifs which are currently 1) CIFS mounts to Samba (and Mac) use Unix Extensions, and mapping characters not needed (its POSIX) 2) CIFS mounts to Windows (no mapping) For the latter the user can choose a mapping (SFU or Mac style) by passing a mount option although we would prefer the Mac style. SFU and SUA, although included in Windows until recently, is not as commonly used as Macs. For SMB3, default to a sane mapping (since no Unix Extensions) - simply use Apple style character mapping. Can be turned off (or if needed for compatibility with older Windows can turn on SFU/SUA mapchars with same mapchars mount option as cifs).
> --- Comment #7 from Steve French <smfrench@gmail.com> --- > We probably don't want to change defaults for cifs which are currently > > 1) CIFS mounts to Samba (and Mac) use Unix Extensions, and mapping characters > not needed (its POSIX) current Macs *do* use the SFM mapping, not mapping-less mode of unix extension. And the current mapping in cifs vfs is very incomplete anyway - this is why I proposed to switch to a complete and commonly used SFM mapping. > 2) CIFS mounts to Windows (no mapping) > > For the latter the user can choose a mapping (SFU or Mac style) by passing a > mount option although we would prefer the Mac style. SFU and SUA, although > included in Windows until recently, is not as commonly used as Macs. there is not even a default mapping for SUA any more. > For SMB3, default to a sane mapping (since no Unix Extensions) - simply use > Apple style character mapping. Can be turned off (or if needed for > compatibility with older Windows can turn on SFU/SUA mapchars with same > mapchars mount option as cifs). I wrote in commment 4 why I strongly disagree to make different defaults based on the protocol version. Please don't do that.
If we can accurately detect that Mac (non-Samba) servers don't handle POSIX file names then (for cifs mounts with Unix Extensions enabled) then the only question is whether we can get agreement from users that they don't mind character mapping enabled by default (obviously if we enable a default character mapping we want to use Mac not SFU/SUA, even if technically more systems, ie millions of Windows systems, could have SFU/SUA installed it is used less). Can you ask on some of the mailing lists if users would object to enabling the Mac mapping by default on cifs mounts - it could affect some users. It is unusual precedent to change default behavior on mounts without changing a version or other features that would signal to the user the change - but I am ok with this if users want the old style cifs (non-Unix/Samba server) behavior to change. Note that I want to change default mount eventually to vers=smb3 (or perhaps add /sbin/mount.smb3 which links to mount.cifs but automatically enables vers=smb3.02 and/or smb3) but getting ACLs working on SMB3 is needed first so we can do the mode mapping properly.
I proposed make the default behaviour to use the Mac mappings for cifs cvs mounts on the linux-cifs mailing list. No objections were raised. Also convmv 2.0 is out which is able to convert existing files from one mapping to another.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/fs/cifs?id=45e8a2583d97ca758a55c608f78c4cef562644d1
*** Bug 13712 has been marked as a duplicate of this bug. ***
Also see the followon patch https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/fs/cifs?id=57c176074057531b249cf522d90c22313fa74b0b which addresses the problem where the trailing space or period is not at the end of the path.