[linux-cifs-client] remapping illegal file characters
Steve French
smfrench at austin.rr.com
Mon Apr 4 05:36:46 GMT 2005
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)
More information about the linux-cifs-client
mailing list