trailing period and trailing space, which are (usually) not allowed on NTFS and SMB should be handled gracefully by vfs_fruit for Mac clients, see http://support.microsoft.com/en-us/kb/kbview/117258 : 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 see also bug 11206 for a related issues with Linux cifs vfs.
see checks like in is_legal_name() from source3/smbd/mangle_hash2.c
ralf and i tested today with w2k8r2 and with win2012r2 ... they no longer disallow trailing dot and trailing space. creation of such names is possible via smb. explorer also shows those files but renaming is not possible so the windows api or explorer can'handle them correctly. as it' possible to create them via smb though i think we also don't need to handle them in a special way in fruit. instrad i suggest we also remove the checks in is_legal_name() to get the same behaviour as current windows versions.
Oh wow. Does that change in filename semantics match the MS-docs on what is a permissable filename ? So currently smbclient can create filenames on Windows that explorer can't rename ? Can explorer delete them ? What about powershell ?
also deleting is not possible. same with powershell. both say that those files do not exist when you want to delete or rename them.
Created attachment 10961 [details] patch to allow trailing spcace and trailing period in smbd/hash2
Created attachment 10962 [details] patch to allow trailing spcace and trailing period in smbd/hash (shouldn't we use a common function in hash/hash2 to check for illegal names?)
(In reply to Jeremy Allison from comment #3) In https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247%28v=vs.85%29.aspx I don't find mentioning of trailing perio or space to be illegal. I thought in previous times it was mentioned there. A comment also says: --snip-- I wanted to make some corrections and answer a few questions. Note, I don't work for MS and probably know more about linux than MS, but I know a few things. To test many of these corrections/answers, I used the 'bash' shell from the cygwin distribution (from cygwin.com). It allows you to get around cmd.exe restrictions, but cannot, obviously, do things that the OS doesn't support. Note that while bash can create Windows incompatible file names (like ones with '*, ?, |, >, etc...'), those that are really NT incompatible will be 'faked' and only display correctly in cygwin (it substitutes a character from the private-code page area in the Unicode character set as a place holder. It will work as the real character in cygwin-based programs, but ISN'T win-compatible. I won't bother to address characters that aren't "REAL" -- i.e. they will display correctly under Windows programs). --snap--
and this part of the comment actually: --snip-- Last point: About spaces and dots in filenames and directories. The limits are in the windows shell -- not in Windows or NT. Using 'bash', you can create files with spaces (or dots), both, at the beginning and end of a filename. You can then list and open those files in explorer, and you can 'list' them in the shell (cmd.exe), but you won't necessarily be able to open them from the shell (especially trailing spaces and dots). The shell strips them out. If you want such things, use another shell, but WARNING -- if you put spaces after your filename, it will be hard to figure out how many there are. To do it, you'd have to dump your directory listing to a file and do a hexdump of the file to see how many space characters there actually are. Not a major problem, but still a bit of a pain. --snap--
(In reply to Björn Jacke from comment #7) Somewhere on the page it says: Do not end a file or directory name with a space or a period
Created attachment 10963 [details] 0001-smbd-mangle-hash-tailing-period-and-space-are-allowe.patch updated patch that removes now unused variable also
Created attachment 10964 [details] patch to allow trailing spcace and trailing period in smbd/hash updated patch that removes now unused variable also
(In reply to Björn Jacke from comment #4) Isn't this a DOS bug ? I can sit in an smbclient loop creating files in a directory that no Windows command can remove....
Applied the patches for both mangle_hash.c and mangle_hash2.c. A directory with a space at the end became unmangled but it appears empty on OS X 10.10.3.
a windows server allows tailing spaces but OS X clients map the trailing space to 0xF028, see bug 11255. Same like windows client behave weird if there are files with unmapped trailing space or period, OS X clients also will. Nonetheless the patches on the server side do what current Windows servers also do these days.
I mean always map tailing space (0x20) on local disc to 0xF028 on the wire and local trailing period (0x2E) to 0xF029 on the wire.
(last comment was meant to go to bug 11255)
(In reply to Björn Jacke from comment #14) > Nonetheless the patches on the server side do what current Windows servers also > do these days. a file with a trailing dot can be created via smbclient but this is actually like a DOS attack because it cannot be deleted/renamed on the windows site. I reported that to the ms secure team when we discussed it here in 2015 but the behavour is still the same these days. Such a trailing dot/space file created by smbclient is also served via SMB by Windows clients "as is" as a plain trailing character. This seems not to be the desired behaviour for Windows either though but that is not our business. I just checked that the MS docs currently clearly forbid trailing dot and space. The best solution for Samba should be to map trailing dot/space to the SFM mapped unicode codepoints and this is what bug 11255 is all about.
To my understanding this is the corresponding patch that will implement the suggested behaviour from https://bugzilla.samba.org/show_bug.cgi?id=11255? Why is it resolved as wontfix then?
It's WONTFIX because this patch is incorrect. Names ending in space or dot are ILLEGAL FILENAMES in the SMB2 protocol. Ignoring that will cause great problems.
Ah, I didn't look at the patch itself. I thought it would introduce the substitution of those characters by the private unicode ones as suggested in the bug I linked, but it turns out this is just deleting the check which would preserve the characters leading to problems on Windows. So yes, totally understandable that this way is not accepted as a patch.