A Windows client has previously stored a file with an alternate data stream into a Samba share. (Thumbs.db and Thumbs.db:encryptable in our initial discovery.)
When Explorer's right-click 'Properties' option is selected, to get the 'size on disk' value, it doesn't descend past the directory containing the Thumbs.db:encryptable file. It turns out that this is being mangled (in both hash and hash2 methods) to a filename ending ".db:" and we suspect that Windows thinks this is a device/illegal file name and gives up.
Creating a file called "thumbs.db:foo" in any directory was enough to recreate the behaviour of Explorer.
Should Samba be returning any such files in its list of filenames in a directory/matching a pattern requested by Explorer? If we veto them in smb.conf, they won't be available if a client explicitly attempts to open an alternate data stream. Perhaps we can just 'fix' the mangling code to treat ':' as not allowed?
I see from the mangle_hash.c code that it should already be treating ':' as an invalid character (has_illegal_chars() called from is_valid_name())
But it apparently does:
[2007/07/24 18:16:01, 5] smbd/trans2.c:(1169)
get_lanman2_dir_entry found openbob/thumbs.db:foo fname=thumbs.db:foo
[2007/07/24 18:16:01, 5] smbd/mangle_hash.c:(615)
name_map( thumbs.db:foo, need83 = False, cache83 = True)
[2007/07/24 18:16:01, 5] smbd/mangle_hash.c:(444)
cache_mangled_name: Stored entry THUMB~9W.DB: -> thumbs.db:foo
[2007/07/24 18:16:01, 5] smbd/mangle_hash.c:(641)
name_map() ==> [THUMB~9W.DB:]
(In reply to comment #0)
> (in both hash and hash2 methods)
I was incorrect. It doesn't happen with hash2.
(But, yes, we stuck with the old hash because of backwards compatibility concerns.)
Created attachment 2841 [details]
patch to mangle_hash.c
This patch skips ':' if it would appear in a mangled 8.3 filename extension.