SMB Share unintelligible file/folder names

[Jet A]

Hi All,

I have an issue when viewing a Freenas Share using/over SMB with one particular client application. When Viewed from the client application any file/folder with a space in it gets mangled/illegible/unintelligible. It would appear that a file/folder with a two or more capital letters or a space are causing the issue. I am unsure if the letters directly translate to anything.

When the files are copied local the problem does NOT persist. When the from internet explorer everything appears fine. (as seen in the screenshot)

Guest mode is enabled
VFS Objects - aio_pthread, streams_xattr, shadow_copy

Drive is mapped with user as nobody

Data set permission type is Windows


Hoping to get some insight as to what may be causing the issue or more important how to resolve.

The client machine is an XP machine Build 2600 SP3

Freenas build

 

[Ericloewe]

The little window you have open is using Windows 3.x APIs. There's your problem.

Filenames are being mangled trying to convert them to 8.3 filenames. Why? I dunno, we're well in "too archaic to work properly" territory.

 

[Jet A]

As it would appear, my original assessment is incorrect. The file/folders are unintelligible when the file/folder is over 8 characters. Does this new information help identify a possible corrective action?

I do understand this is probably "too archaic to work properly ", and researching 8.3 filenames which lead me to the 8 character validation.

I am open to suggestions on how to work around the issue, short of renaming all customer file/folders into an 8 character name.

 

[anodos]

As it would appear, my original assessment is incorrect. The file/folders are unintelligible when the file/folder is over 8 characters. Does this new information help identify a possible corrective action?

I do understand this is probably "too archaic to work properly ", and researching 8.3 filenames which lead me to the 8 character validation.

I am open to suggestions on how to work around the issue, short of renaming all customer file/folders into an 8 character name.

Use a better client.

 

[Jet A]

Wish I could, not an option. Software runs legacy CNC equipment. Upgrading is cost prohibitive.

 

[Ericloewe]

Wish I could, not an option. Software runs legacy CNC equipment. Upgrading is cost prohibitive.

Well, you're stuck in legacyland, with all that implies.

The names are being incorrectly mangled, but I don't even know where to begin investigating that one. Windows 3.x-era software running on Windows XP on modern Samba is a nightmare configuration.

 

[anodos]

Well, you're stuck in legacyland, with all that implies.

The names are being incorrectly mangled, but I don't even know where to begin investigating that one. Windows 3.x-era software running on Windows XP on modern Samba is a nightmare configuration.

The names are being correctly mangled. The default is to use a tilda "~" and the first character of the file / directory name. Remaining characters are the result of a hashing algorithm. You can increase the number of unhashed characters by using the mangle prefix smb.conf parameter. The default is mangle prefix=1, but you can preserve up to five characters. When you increase the number of un-hashed characters, you increase the probability of a hash collision (bad thing).

 

[Ericloewe]

The names are being correctly mangled. The default is to use a tilda "~" and the first character of the file / directory name. Remaining characters are the result of a hashing algorithm. You can increase the number of unhashed characters by using the mangle prefix smb.conf parameter. The default is mangle prefix=1, but you can preserve up to five characters. When you increase the number of un-hashed characters, you increase the probability of a hash collision (bad thing).

I thought the default was four or five, to match what Windows tends to do. Goes to show how much I deal with 8.3 filenames.

 

[anodos]

I thought the default was four or five, to match what Windows tends to do. Goes to show how much I deal with 8.3 filenames.

To be fair, from what I understand samba's original hashing produced lots of collisions, hence they used more characters. Later it was improved, but I guess the default remained the same.

 

[Jet A]

Setting mangle prefix=5 allowed enough to be legible to work with. Many Thanks!

What happens to the data when a has collision occurs?

 

[Ericloewe]

Setting mangle prefix=5 allowed enough to be legible to work with. Many Thanks!

What happens to the data when a has collision occurs?

The data itself should be fine, but expect the client to be unable to access the directory in weird and wonderful ways.