[Samba] XP Clients Showing Incorrect Filenames
TAKAHASHI Motonobu
monyo at monyo.com
Sat May 28 02:09:48 MDT 2011
From: Andy Theuninck <gohanman at gmail.com>
Date: Fri, 27 May 2011 11:01:36 -0500
> I'm seeing something fairly odd where XP clients show some - but not
> nearly all -filenames as a random jumble of characters.
This is by design. Samba uses hash2 method to generate short
filenames. According to the old document, by default an 8+3 file name
is constructed as
1st byte : The first of the filename (if ASCII)
2nd - 6th bytes: hashed value from the filename
7th : ~
8th : hashed value from the filename
Also the first 3 bytes from extension becomes the 3 byte extension.
> The odd file names all look like "AH6I10~Z". Besides the tilde always
> being 2nd to last, the other characters don't have any consistent
> mapping to the actual file name.
This odd filename is valid for hash2 method. And about the extension
see the BUG#7719.
From: Andy Theuninck <gohanman at gmail.com>
Date: Fri, 27 May 2011 12:39:07 -0500
> On a sidenote, the behavior would be tolerable if it wasn't removing
> the file extension and thus Windows' ability to identify file type. So
> it's more like just 8 shortening; the .3 part is missing.
I've already posted this bug:
Long extensions aren't shortened correctly in mangled names
https://bugzilla.samba.org/show_bug.cgi?id=7719
I examined this behavior against at least Samba 3.0.24/3.2.4/3.5.4.
I found other bug in hash2 method that if the extension contains
non-ASCII chars, the extension of short filename is vanished.
Anyway hash2 method generates mostly "randomized" filename so it's
very inconvinient. I hope the short filename is generated with the
same method as Windows and stored in EA.
P.S.
hash method is also completely broken:
Bug 1521 - SFN process must be based on dos charset, not UCS2
and also this method sometimes generates same short filename as
described at smb.conf(5).
---
TAKAHASHI Motonobu <monyo at samba.gr.jp>
More information about the samba
mailing list