Mac dirs don't use correct APIs to look up names about dirs-rs HOT 13 CLOSED

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?

from dirs-rs.

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.

from dirs-rs.

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

from dirs-rs.

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.

from dirs-rs.

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?)

from dirs-rs.

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.

from dirs-rs.

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

from dirs-rs.

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.

from dirs-rs.

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

from dirs-rs.

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.

from dirs-rs.

@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.

from dirs-rs.

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

from dirs-rs.

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?

from dirs-rs.