Bug 6939 - mangling method = hash breaks long filenames
mangling method = hash breaks long filenames
Product: Samba 3.4
Classification: Unclassified
Component: File services
All All
: P3 critical
: ---
Assigned To: Karolin Seeger
Samba QA Contact
Depends on:
  Show dependency treegraph
Reported: 2009-11-30 05:33 UTC by Björn Jacke
Modified: 2009-12-24 00:27 UTC (History)
2 users (show)

See Also:

git-am format patch for 3.4.4. (1.03 KB, patch)
2009-12-17 18:23 UTC, Jeremy Allison
bjacke: review+
git-am format patch for 3.3.x (1.02 KB, patch)
2009-12-17 18:38 UTC, Jeremy Allison
bjacke: review+

Note You need to log in before you can comment on or make changes to this bug.
Description Björn Jacke 2009-11-30 05:33:18 UTC
setting mangling method = hash will result in only getting hashed short filenames, no long file names there anymore.
Comment 1 Mike 2009-12-11 17:52:29 UTC
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.
Comment 2 Mike 2009-12-11 23:15:10 UTC
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...)
Comment 3 Björn Jacke 2009-12-17 04:50:23 UTC
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.
Comment 4 Jeremy Allison 2009-12-17 16:08:15 UTC
Ok, I'll take a look at it asap.

Comment 5 Jeremy Allison 2009-12-17 18:23:34 UTC
Created attachment 5096 [details]
git-am format patch for 3.4.4.
Comment 6 Jeremy Allison 2009-12-17 18:38:26 UTC
Created attachment 5097 [details]
git-am format patch for 3.3.x
Comment 7 Björn Jacke 2009-12-18 10:26:58 UTC
Comment on attachment 5096 [details]
git-am format patch for 3.4.4.

looks good, tested successfully. Thanks for the fast patch, Jeremy!
Comment 8 Karolin Seeger 2009-12-21 05:08:44 UTC
Pushed to v3-3-test and v3-4-test.
Closing out bug report.

Comment 9 Mike 2009-12-21 19:16:55 UTC
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:
is being returned in directory lists as:

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.
Comment 10 Jeremy Allison 2009-12-21 19:30:54 UTC
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.


Comment 11 Jeremy Allison 2009-12-21 19:49:21 UTC
Ok, I already have a fix for this (easy to reproduce). Please open the new bug and I'll attach the fix there.