setting mangling method = hash will result in only getting hashed short filenames, no long file names there anymore.
I just got bit by this bug after upgrading from 3.2.5 It seems to impact 3.4.2 as well (thats where I went first before 3.4.3) We have mangling method = hash set for a legacy DOS application. (one day they'll upgrade... one day...) But we are also in need of the latest samba releases for Win7 compatibility. This is at the server level, since all clients get the mangled names. (DOS, smbclient, WinXP). Once I comment out "mangling method = hash" (and take the default hash2) the long filenames are visible.
Correction on the above comment: I cannot verify that this worked at 3.2.5 It turns out the users never tested the DOS app at that level (only the Win7 client). So the last known level at which this worked for me was 3.0.24 I did a quick diff of mangle_hash.c at all three (3.0, 3.2, 3.4) levels, and there isn't much that changed. The best I can find is that 3.0 used to simply ignore requests to mangle if the filename didn't "need83". In the 3.2/3.4 levels there is now a separate must_mangle function which presumably is used as a check to bypass mangling altogether as needed. (Not seeing anything broken there, however...)
Jeremy, do you have time to look at this? It's a regression from Samba 3.0.x to 3.2. If possible we should fix this for one the next 3.4 releases. Karolin: We should in any case add something like a "KNOWN BUG" section into the release notes as long as we have this bug.
Ok, I'll take a look at it asap. Jeremy.
Created attachment 5096 [details] git-am format patch for 3.4.4.
Created attachment 5097 [details] git-am format patch for 3.3.x
Comment on attachment 5096 [details] git-am format patch for 3.4.4. looks good, tested successfully. Thanks for the fast patch, Jeremy!
Pushed to v3-3-test and v3-4-test. Closing out bug report. Thanks!
I just got a chance to test the fix this weekend, and there still seems to be problems with mangling method = hash. Specifically, I am finding that directories with a period are being stripped of the last segment of the name (as if they were having their 8.3 extension removed.) For example: <user>/Profile/OpenOffice.org/ is being returned in directory lists as: <user>/Profile/OpenOffice/ This is happening to Windows as well as smbclient, preventing rollout of the fix. If you try to access the "OpenOffice" directory without the ".org" you get a failure trying to find the file. If you use "OpenOffice.org" it works. It turns out that quite a few organizations (OO.org, Adobe/Macromedia, etc) are using a website name as a their folder in our user's roaming profiles. Windows freaks when it can't copy files from the profile. Otherwise, the fix is perfect. The DOS programs are working great again. Thanks for the quick turnaround. Let me know if this needs to be a new bug, or if you need more information.
This is a new bug. Can you open a new bug please and attach the last comment as the report and I'll take a look. Thanks, Jeremy.
Ok, I already have a fix for this (easy to reproduce). Please open the new bug and I'll attach the fix there. Jeremy.