Bug 5857 - "mangling method = hash" seems to break smbd
Summary: "mangling method = hash" seems to break smbd
Status: RESOLVED DUPLICATE of bug 1521
Alias: None
Product: Samba 3.2
Classification: Unclassified
Component: File services (show other bugs)
Version: 3.2.3
Hardware: x86 Linux
: P3 normal
Target Milestone: ---
Assignee: Samba Bugzilla Account
QA Contact: Samba QA Contact
Depends on:
Reported: 2008-10-28 19:05 UTC by onetime128
Modified: 2008-11-19 19:49 UTC (History)
2 users (show)

See Also:

The result of dir /a /x (54.92 KB, image/tiff)
2008-11-11 08:41 UTC, TAKAHASHI Motonobu
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description onetime128 2008-10-28 19:05:37 UTC
I use Windows 98 client to connect to a samba share, and it generally works fine. After a recent Debian update, I tried to adjust the 8.3 mangling parameters; namely, I tried to find a way to make the whole hash suffix appear AFTER the tilde, as opposed to just the last 1 character (which is a great nuisance, because one can't see where the file name ends and the suffix begins; I really wish there was an option to control this).

Anyway, I couldn't find a way to do that with the 'hash2' method, so I tried to use the old 'hash' method. But when I use that, the server starts to misbehave in strange ways.

First, it stops responding for quite a while; no error message is printed anywhere.

Then, it resumes operation, but instead of mangling just the 8.3 short names, the long filenames are mangled too. In addition to that, files begins to disappear from the share - some folders are listed empty, some half-empty. And some files even change names when different client applications are used to list them. It seems as if the filesystem was somehow corrupt.

When mangling method is reset to 'hash2', the server goes back to working normally, but setting it to 'hash' trigger the anomalous behavior every time.
Comment 1 TAKAHASHI Motonobu 2008-11-11 08:41:26 UTC
Created attachment 3722 [details]
The result of dir /a /x
Comment 2 TAKAHASHI Motonobu 2008-11-11 08:42:06 UTC
I found this bug, too during checking BUG #1521.
Comment 3 Jeremy Allison 2008-11-19 19:49:41 UTC

*** This bug has been marked as a duplicate of 1521 ***