Mac dirs don't use correct APIs to look up names

[lambda]

On macOS, the names of the various system-created directories like Library, Music, etc can vary based on the user's locale.

This crate simply hard-codes paths such as home_dir().map(|h| h.join("Music")), which won't always find the correct directory.

Instead, the NSSearchPathForDirectoriesInDomains should be used to find the appropriate path to look for.

[soc]

Hi @lambda, thanks for the report – I assumed that the adaption to the locale was happening at the UI level. Do you have further information on this?

[jfro]

I can report a similar problem that we currently wrote code to work around dirs when on macOS/iOS, would be something we can possibly PR for dirs-sys which uses the native ObjC APIs as lambda mentioned above. This likely can fix:

1. Locale issue like lambda's
2. Sandboxing issues, if you're using dirs within a macOS app that's sandboxed or an iOS app which are always sandboxed, you might hit issues like I think I recall we did when running on iOS, home is different and not based on the user.

[soc]

Ok, weird. I had assumed that the folder names were translated in the UI layer for user-firendliness, but were not locale-dependent.

[jfro]

I think it might depend on what locale the system was installed via? but don't quote me on that. As I can safely change my locale while those paths remain the same.

[soc]

So what happens to NSSearchPathForDirectoriesInDomains when to locale is changed?

(Is there some config file that stores the paths with which the account was created?)

[jfro]

I'd have to test, but my understanding is the paths are fixed upon user creation, so if locale is changed later it won't change the paths. But NSSearchPathForDirectoriesInDomains will always return the appropriate path that leads to the user's/system's various folders as they currently exist on the drive.

I can do some testing and maybe work on a PR sometime, the big issue for us is ensuring sandboxing doesn't break dirs as we tend to at least use some rust code on iOS as well.

[soc]

@jfro Would appreciate that! Is there some sys crate for calling NSSearchPathForDirectoriesInDomains?

[jfro]

I'd have to check if it's in any of the foundation crates... our work around we made uses the objc crate to call NSFileManager in Objective-C land which is the slightly higher level version. Forget if there's a reason to use one over the other, both deal with Objective-C classes. objc has some macros that smoothed that over so I could get a C string out of it all.

[jfro]

I started on it, first step was the sys crate: dirs-dev/dirs-sys-rs#6
Thinking can do a PR on this crate once there's a version of dirs-sys to point it at with these changes

[lambda]

I should probably mention that I haven't confirmed what I wrote in the original message; this was not based on a problem I've observed, but my (possibly mistaken) understanding of why there's an API call to retrieve these values, and noticing that they were hardcoded instead of calling that API.

So please make sure to confirm that this problem is real! I hope I don't cause people to do extra work for nothing.

[jfro]

@lambda I'm unable to confirm the locale problem but the sandbox one is real as that has hit me, but that's more of a sandbox homedir vs regular homedir situation.

I can ask a co-worker that might be able to check, think there's at least 2 that likely have their systems in non-english from install/purchase.

[soc]

According to Apple documentation, "display names" are purely a display layer concern:

Display names do not affect the actual name of the file in the file system. Code that accesses a file or directory programmatically must specify the item’s actual name when opening or manipulating the item using the file system interfaces.

source

[soc]

I'd tend to close this, and if something comes out of the sandboxing issue, create a new issue for that. What do you think?