SMB shares: what determines macOS Finder icon?

[anodos]

FreeNAS 11 used cythonized mDNSResponder for doing mDNS advertisements. 12/13/SCALE all use avahi. The model is determined here: https://github.com/truenas/middlewa.../etc_files/local/avahi/avahi_services.py#L106

Auxiliary parameters are not expected to update configuration of other services and are in general not a supported way of configuring the server. They mostly exist for enthusiasts to tinker with things if they wish.

 

[seanm]

I still see a mishmash of icons with TrueNAS 12.0-U8.1 and macOS 12.5.

I see RackMac in the Network section of Finder, that's from mDNS I suspect. But if I connect by FQDN I see an iMac icon. In the Finder sidebar I see either an iMac icon or a generic file icon! I suspect these are macOS Finder bugs.

 

[anodos]

I still see a mishmash of icons with TrueNAS 12.0-U8.1 and macOS 12.5.

I see RackMac in the Network section of Finder, that's from mDNS I suspect. But if I connect by FQDN I see an iMac icon. In the Finder sidebar I see either an iMac icon or a generic file icon! I suspect these are macOS Finder bugs.

View attachment 57765

Finder is indeed problematic at times. Exact icons / behavior varies depending on OSX version.

 

[seanm]

I encourage anyone that wants to see this fixed to file a bug with Apple at https://feedbackassistant.apple.com Duplicate reports increase priority. You can reference mine (FB8984475) as a dupe.

 

[anodos]

I encourage anyone that wants to see this fixed to file a bug with Apple at https://feedbackassistant.apple.com Duplicate reports increase priority. You can reference mine (FB8984475) as a dupe.

If you're going to file duplicate tickets, you should file ones for the fact that finder will silently truncate / corrupt resource forks if there is any sort of unexpected server return during writes (i.e. not STATUS_OK). It's pretty trivial to reproduce.

 

[seanm]

Sure, if you give me the text of your report (by email if you want) I'll file a dupe!

 

[anodos]

Here's the repro if you create a file with a large resource fork you can do the following:


Finder does not pass the IO error up to the user. Shell tools also unexpectedly succeed when they should fail:

Code:

 sh-3.2# cp -r /Users/awalker/Downloads/ICNS\ folders/Capsule\ AirPort /Volumes/share/untitled\ folder/
cp: /Users/awalker/Downloads/ICNS folders/Capsule AirPort/Icon\r: could not copy extended attributes to /Volumes/share/untitled folder/Capsule AirPort/Icon\r: Input/output error
sh-3.2# echo $?
0 

I'd expect non-zero return here. Actual fsetxattr call fails as expected:

Code:

 fsetxattr(0x4, 0x7F89AFD05E65, 0x7F89B1901000)         = -1 Err#5

errno 5 == EIO. So blame lies squarely in userspace tools.

That's the terse form with repro example. The MacOS SMB client does the right thing, but finder, cp, et al do the wrong thing and truncate / corrupt the file.


I filed the first bug report about 5 years ago. :)