vfs_fruit must handle trailing period and space mapping to and from Unicode private range, because the OS X client will always map them. See bug #11207.
*** Bug 11965 has been marked as a duplicate of this bug. ***
I think we should consider to map trailing period and tailing space unconditionally in smbd.
Linux cifs vfs maps them the same way as OS X clients since d2809afc253bf6c90e15.
Windows clients would at least be able to read the files with trailing period and tailing space (which would just stay private unicode glyphs there accordingly).
Can you explain exactly what you're proposing ? In terms of incoming encodings -> smbd transformation -> disk storage and then disk storage -> smbd tranformation -> outgoing encoding ?
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.
b704e70b7cf48f9b67c07d585168e102dfa30bb4 is the correct git hash for the change in cifs vfs
... and the always apply the reverse mapping from wire encoding to local "encoding"
Instead of name mangling trailing '.' and ' ' (dot and space) we should map those characters to the Unicode private range.
The following vfs_catia config illustrates this:
vfs objects = catia
catia:mappings = 0x20:0xf028,0x2e:0xf029
But we need this in the path translation and mapping subsystems.
We still see this issue in the 4.10 branch; whereby an OS X client cannot see a folder that ends in a trailing space. Using 'catia:mappings = 0x20:0xf028,0x2e:0xf029' shows the folder and allows it's contents to be removed, however the folder results in an error -8003.
Could you advise what the current recommendations around this are?
Unfortunately preventing the creation of these files is not possible, as they are being recovered from long term backups, and already have these invalid file names.