[linux-cifs-client] remapping illegal file characters

[Steve French]

Jeremy Allison wrote:

>On Sat, Apr 02, 2005 at 10:30:23PM -0600, Steve French wrote:
>  
>
>>Samba probably ought to be doing the same kind of remapping (as Windows 
>>does in SFU) so that  NFS users and local users can see the same file 
>>names as the remote users.
>>
>>A test patch for the cifs client (remaps the illegal characters, except 
>>for '*' (which is hard because it is needed for readdir - and can not be 
>>globally mapped).  This patch allows you to create, view, list, stat, 
>>remove etc. files with six of the seven key filename characters (legal 
>>to Linux/Unix, illegal to Windows).
>>   :  < > | ? \
>>
>>This allows recognizing/using remotely files created by SFU on Windows 
>>servers as well.
>>    
>>
>
>Ok, just a quick question - so you want Samba file servers to detect
>these unicode private space remappings on filename input for the Linux
>CIFS client and map them to the correct filename characters, and then
>on returing any filenames in info levels/findfirst/next map them to
>the unicode private space ?
>
>Correct ?
>
>Jeremy.
>
>  
>
I suggest/prefer that Samba do the following:

Make it an smb.conf parm but with sensible default behavior e.g:
1) For clients which negotiate the CIFS Unix extensions dialect such as 
the Linux CIFS client
(and probably anyone that negotiates POSIX 2) - allow  open/create and 
mkdir on
filenames (unmapped) with such characters - and do not mangle their
names on FindFirst/FindNext.  This may be hard - so I don't want to push 
the point, but doing
this would fix the strange case in which 1/2 of the operations (delete, 
rmdir, QPathInfo) work
today and 1/2 don't (open, mkdir, FindFirst).

2) For the case of at least Windows clients which are recent enough to 
have Windows SFU, remap
the seven reserved characters so the filenames look right to apps on the 
local server box.
Since once SFU is installed (there may be other cases in which they show 
up too)
awkward looking filenames (e.g. with 0xF03C, etc.) can start showing up on
the Samba server on the local Linux/Unix filesystems with remapped 
characters which are hard to read
and manipulate.

On the client side, I still have to handle at least two cases (and I 
have just added a mount option "mapchars"):
1) The Windows case in which the seven characters are reserved and must 
be remapped
2) A (future) case in which the server allows the seven characters and 
(current) case in which Samba handles them 1/2 of the time.

This turned out to be harder than I expected (and my 1st quick and dirty 
patch that I posted to the list had various problems
and restrictions) but I am now partway through a better solution and 
have updated linux-cifs-client svn on samba.org
with a partial implementation (also includes the lsattr client support 
too) for 1.32 version of cifs vfs.  The FC3/RHEL4 version
(should work on 2.6.8 or later kernels) is also updated and a gz is on 
the ftp site 
http://svn.samba.org/samba/ftp/cifs-cvs/cifs-1.32-forFC3orRHEL4orSuSEWrk9.2or2.6.9kernels.tar.gz
and the module itself
http://svn.samba.org/samba/ftp/cifs-cvs/cifs.ko.version1.29-for-RHEL4

It requires that CONFIG_CIFS_EXPERIMENTAL be #defined

The 1st half of this (the Unicode -> ASCII half) on the Linux cifs 
client is available as a patch at 
http://cifs.bkbits.net:8080/linux-2.5cifs/gnupatch@4250bbcbPSkXcU2T_ZV808KzyzpLqg

I am only remapping the seven characters as follows, those that I 
actually see getting remapped in Windows:

+#define UNI_ASTERIK     cpu_to_le16('*' + 0xF000)
+#define UNI_QUESTION    cpu_to_le16('?' + 0xF000)
+#define UNI_COLON       cpu_to_le16(':' + 0xF000)
+#define UNI_GRTRTHAN    cpu_to_le16('>' + 0xF000)
+#define UNI_LESSTHAN    cpu_to_le16('<' + 0xF000)
+#define UNI_PIPE        cpu_to_le16('|' + 0xF000)
+#define UNI_SLASH       cpu_to_le16('\\' + 0xF000)