Bug 5857 - "mangling method = hash" seems to break smbd
"mangling method = hash" seems to break smbd
Status: RESOLVED DUPLICATE of bug 1521
Product: Samba 3.2
Classification: Unclassified
Component: File services
x86 Linux
: P3 normal
: ---
Assigned To: Samba Bugzilla Account
Samba QA Contact
Depends on:
  Show dependency treegraph
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 ***