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.