[Mono-dev] Patch for environment specific location for .mono folder

Tom Philpot tom.philpot at logos.com
Tue Jun 1 16:46:56 EDT 2010


On third thought, the patch below may not be that necessary for our case as the XDG_DATA_HOME, XDG_CONFIG_HOME and MONO_SHARED_DIR can all be remapped based on environment variables. The Registry code UnixRegistryApi.cs assumes that .mono will live under the folder returned by g_get_home_dir() and several of the Makefiles that deal with the Registry assume this value is $HOME, but for our app, it's easier to just make sure we don't use the Registry than to hack Mono to that level.

I suppose one could just add a MONO_USER_REGISTRY_PATH environment variable, but that just increases the proliferation of environment variables that one has to account for.

Remapping internalGetHome() to something other than the value of g_get_home_dir() is just a fantastically bad idea.

Tom


On Jun 1, 2010, at 10:47 AM, Zoltan Varga wrote:

Hi,

  The relevant code in aot-runtime.c is just some experimental code, its not used by anyone, so you can ignore it.

                          Zoltan

On Tue, Jun 1, 2010 at 7:42 PM, Tom Philpot <tom.philpot at logos.com<mailto:tom.philpot at logos.com>> wrote:
After digging a little bit further, it seems there are more issues with this patch:

First, the AOT-Runtimes assumes that .mono is under g_get_home_dir()

Secondly, System.Environment.SpecialFolder.Personal returns internalGetHome which is g_get_home_dir()

Does it make sense to change this to a MONO_USER_HOME environment variable that takes precedence over g_get_home_dir(), and then update references to g_get_home_dir() to check MONO_USER_HOME first?

This would be really useful for use, and possibly others I'd expect.

Tom




On Jun 1, 2010, at 9:44 AM, Tom Philpot wrote:

> Attached is a patch that allows the user (or an embedded application) to set MONO_USER_CONFIG to specify a directory location for the .mono folder, similar to the MONO_CONFIG environment variable for mono configuration folder.
>
> We have an app which embeds Mono and we'd like to be certain that other Mono apps won't be tinkering with our configuration. This also allows us to make sure that the .mono folder can be created/updated as certain users don't have write access to their home folder, but do have access to sub-folders. We'd prefer not to have to ask for elevated permissions just to create a hidden config folder. Finally, this allows our application not to scatter configuration information throughout the file system as we can put all our configuration under an application specific folder.
>
> This patch is MIT/X11 licensed.
>
>
> Index: mono-config.c
> ===================================================================
> --- mono-config.c     (revision 158291)
> +++ mono-config.c     (working copy)
> @@ -560,7 +560,9 @@
>       g_free (mono_cfg);
>
> #ifndef TARGET_WIN32
> -     home = g_get_home_dir ();
> +     home = g_getenv ("MONO_USER_CONFIG");
> +     if (home == NULL)
> +             home = g_get_home_dir ();
>       user_cfg = g_strconcat (home, G_DIR_SEPARATOR_S, ".mono/config", NULL);
>       mono_config_parse_file (user_cfg);
>       g_free (user_cfg);
>
> Thanks,
> Tom
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com<mailto:Mono-devel-list at lists.ximian.com>
> http://lists.ximian.com/mailman/listinfo/mono-devel-list

_______________________________________________
Mono-devel-list mailing list
Mono-devel-list at lists.ximian.com<mailto:Mono-devel-list at lists.ximian.com>
http://lists.ximian.com/mailman/listinfo/mono-devel-list


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20100601/2afe4434/attachment.html 


More information about the Mono-devel-list mailing list