Bug 8525 - Environment.SpecialFolder.CommonApplicationData returns non-existant folders
Summary: Environment.SpecialFolder.CommonApplicationData returns non-existant folders
Alias: None
Product: MonoMac
Classification: Desktop
Component: Bindings ()
Version: unspecified
Hardware: PC Mac OS
: --- normal
Target Milestone: ---
Assignee: Bugzilla
Depends on:
Reported: 2012-11-20 06:02 UTC by Steve
Modified: 2015-02-11 13:58 UTC (History)
3 users (show)

Is this bug a regression?: ---
Last known good build:

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.

Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:

Description Steve 2012-11-20 06:02:53 UTC
Environment.SpecialFolder.CommonApplicationData returns "/usr/share" when no such folders exist.
I do, however, have "/Users/Shared" folder structure.
I'm running on OSX 10.8.2 with MonoDevelop 3.0.5.

Comment 1 Jonathan Pryor 2012-11-20 10:10:30 UTC
You don't have a /usr/share directory? I do, also on OS X 10.8.2:

    $ ls -lFd /usr/share
    drwxr-xr-x  58 root  wheel  1972 Oct 13 15:10 /usr/share/

I'm also on OS X 10.8.2, though I suppose that /usr/share could have been created by something other than the OS, but I doubt it given that OS X provides `vim` and has a `/usr/share/vim` directory...

Now, perhaps Environment.SpecialFolder.CommonApplicationData shouldn't be /usr/share, but I doubt that /Users/Shared makes any sense at all; `/Users/Shared/Library/Application Support` would make far more sense, were it to change at all, and "while at it" the other SpecialFolder.Common* members could be mapped to corresponding subdirectories in /Users/Shared, e.g. SpecialFolder.CommonDesktopDirectory could be /Users/Shared/Desktop.

Whether that much mapping makes any sense, on the other hand... (Does OS X _do_ anything with /Users/Shared/Desktop? I suspect that would make no sense at all. Ditto most of the other Common* members...)
Comment 2 Steve 2012-11-29 04:03:13 UTC
Hi Jonathan,

I'm new to Apple/Mac/Mono and have a C sharp application that I'm looking to migrate.

I currently use the Environment.SpecialFolder.CommonApplicationData in the Win version of my application for storing user data, so naturally assumed that functionality would be reproduced via Mono on the Mac.

I cannot see a /usr/share with Finder, and the code returns an exception as it cannot find - or possibly more correctly access (should it exist as in your case). But as I am not yet familiar with the set-up of the Mac to see hidden folders etc. I cannot find if such a folder exists.

Basically, I'd like the functionality to behave in a similar fashion to windows and return a common user area for storage of data that has read/write access, so I can write an application that can work for any user (of any experience level) on their Mac. 

Hope that helps,

Comment 3 Jonathan Pryor 2012-11-29 08:22:59 UTC
> I cannot see a /usr/share with Finder

Doesn't mean anything; Finder hides _lots_ of directories. You need to use Terminal.app along with the normal Unix utilities to view them (ls, find, etc.).

> the code returns an exception as it cannot find - or possibly
> more correctly access (should it exist as in your case).

If you're trying to write to /usr/share, you'll have a problem: filesystem permissions won't allow it:

    $ ls -ld /usr/share
    drwxr-xr-x  58 root  wheel  1972 Oct 13 15:10 /usr/share

Unless your software is running as `root` or is part of the `wheel` group (hint: it probably isn't), your app won't have write access to /usr/share. It _will_ have read access.

> return a common user area for storage of data that has read/write access,

Offhand, I'm not aware of any such area on OS X.

You could _create_ such an area by writing an installer (Google "packagemaker"), and have your installer create a world-writable directory within /usr/share.

However, this would likely be a security vulnerability waiting to happen; I wouldn't recommend it.

> so I can write an application that can work for any user 

I do not see why "an application that can work for any user" would require write access to CommonApplicationData. Read-access, certainly (templates, etc.), but write access?
Comment 4 Steve 2012-12-02 10:48:53 UTC
OK, so I should write my data to the folder where the executable resides?
 - I assume this is possible - have not yet tested this assumption - as I will need to get something working first as the Mono development directories will have write permission.
Comment 5 Jonathan Pryor 2012-12-02 17:41:39 UTC
> I should write my data to the folder where the executable resides

Often this will not work:

> $ ls -lFd /Applications/*.app
> drwxrwxr-x  3 root  admin  102 May 18  2011 /Applications/Adobe Reader.app/
> drwxr-xr-x+ 3 root  wheel  102 Oct 26 15:27 /Applications/App Store.app/
> drwxr-xr-x  4 root  wheel  136 Jun  6 13:22 /Applications/Linkinus.app/
> drwxr-xr-x  3 jon   admin  102 Jul 10  2011 /Applications/MacVim.app/

Apps that come with the OS (App Store.app) are root/wheel. Apps that are installed via an installer (Adobe Reader) are root/admin. Apps that are installed by you dragging them into /Applications are YourUserName/admin.

In no case is an App directory world-writable (security!), and the few that are group writable are in the admin, wheel, or "staff" groups. ("staff" is ~every user on the machine, but I have _one_ app installed which is writable by staff: Android File Transfer.app. I suspect it's a fluke, and Bad Security™. admin & wheel are obviously highly restricted.)

So I would say that in no _sane_ circumstance would an app have a world-writable directory, so writing data from the folder where the executable resides is probably a non-starter.

(The same should also be true on Windows, where usually Program Files is locked down to prevent arbitrary write access...  You know, Security!)

If at all possible, I'd suggest ApplicationData or LocalApplicationData. These are (unfortunately?) per-user, but should always be writable.
Comment 6 Timothy Risi 2015-02-11 13:58:37 UTC
Closing since the original bug was invalid.  A new bug can be created if necessary for the rest of the discussion