Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
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
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.
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.
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...)
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,
> 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?
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.
> 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.
Closing since the original bug was invalid. A new bug can be created if necessary for the rest of the discussion