This MR has a similar goal !3259, but the difference is that this MR aims to only isolate the XDG user dirs and nothing else. This is entirely possible to do through winecfg, but the problem with using winecfg is that you would have to manually run it on every new wineprefix, and therefore to automate this process without winecfg would require a manual removal of the symlinks. My solution was to create a simple on/off environment variable to disable or enable the creation of the symlinks.
-- v2: shell32: Add environment variable to prevent symlinking home folders.
From: Etaash Mathamsetty etaash.mathamsetty@gmail.com
--- dlls/shell32/shellpath.c | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/dlls/shell32/shellpath.c b/dlls/shell32/shellpath.c index 015d7cdd4e2..d32eba55b9b 100644 --- a/dlls/shell32/shellpath.c +++ b/dlls/shell32/shellpath.c @@ -2641,6 +2641,7 @@ end:
static char *xdg_config; static DWORD xdg_config_len; +static BOOL do_symlink = TRUE;
static BOOL WINAPI init_xdg_dirs( INIT_ONCE *once, void *param, void **context ) { @@ -2650,6 +2651,14 @@ static BOOL WINAPI init_xdg_dirs( INIT_ONCE *once, void *param, void **context ) HANDLE file; DWORD len;
+ if (_wgetenv( L"WINEISOLATEHOME" )) + { + do_symlink = FALSE; + xdg_config = NULL; + TRACE("WINEISOLATEHOME is set, not creating symlinks to user home\n"); + return TRUE; + } + if (!(var = _wgetenv( L"XDG_CONFIG_HOME" )) || var[0] != '/') { if (!(var = _wgetenv( L"WINEHOMEDIR" ))) return TRUE; @@ -2779,7 +2788,7 @@ done: * _SHCreateSymbolicLink [Internal] * * Sets up a symbolic link for one of the special shell folders to point into - * the users home directory. + * the users home directory. Will not do so when WINEISOLATEHOME is set. * * PARAMS * nFolder [I] CSIDL identifying the folder. @@ -2788,6 +2797,8 @@ static void _SHCreateSymbolicLink(int nFolder, const WCHAR *path) { DWORD folder = nFolder & CSIDL_FOLDER_MASK;
+ if (!do_symlink) return; + switch (folder) { case CSIDL_PERSONAL: create_link( path, "XDG_DOCUMENTS_DIR", "$HOME/Documents" );
FWIW, I still don't think it's a bad idea to allow being more selective. If just the `Z:` folder was the issue, I would have split that off. But this MR doesn't adress any of the problems Alexandre mentioned:
So why do we need a separate mechanism, with an ad-hoc environment variable? Why is it only usable at prefix creation? Is there a way to unify the features, or make them easier to use? How is it different from `winetricks sandbox`? etc. etc.
If we add `WINEISOLATEHOME` and later decide we want to have `Z:` isolated as well, we'd need `WINEISOLATEROOT` as well, and I'd personally much prefer a WINEISOLATE with options like WINEDEBUG.
On Sun Dec 3 07:43:05 2023 +0000, Fabian Maurer wrote:
FWIW, I still don't think it's a bad idea to allow being more selective. If just the `Z:` folder was the issue, I would have split that off. But this MR doesn't adress any of the problems Alexandre mentioned:
So why do we need a separate mechanism, with an ad-hoc environment
variable? Why is it only usable at prefix creation? Is there a way to unify the features, or make them easier to use? How is it different from `winetricks sandbox`? etc. etc. If we add `WINEISOLATEHOME` and later decide we want to have `Z:` isolated as well, we'd need `WINEISOLATEROOT` as well, and I'd personally much prefer a WINEISOLATE with options like WINEDEBUG.
For the first point Alexandre made: I think the reason for having the separate mechanism are pretty clear, at least to me. Points 2 and 3: The only usable at prefix creation is a feature, winecfg can be used to configure it after the creation of the prefix and this variable can be used to configure it beforehand (or something along those lines). Point 4: It's different since you can set this variable before the prefix is created and additionally you won't need to use a helper script that you have to download on the side to achieve a rather common use case of isolating the home dir folders.
I'm not exactly sure if there's a negative to adding a second env variable for isolating the Z: drive, I feel like they should have different variables because they do vastly different things. Both ways feel valid to me, but one is a lot easier to implement
On Sun Dec 3 07:49:14 2023 +0000, Etaash Mathamsetty wrote:
For the first point Alexandre made: I think the reason for having the separate mechanism are pretty clear, at least to me. Points 2 and 3: The only usable at prefix creation is a feature, winecfg can be used to configure it after the creation of the prefix and this variable can be used to configure it beforehand (or something along those lines). Point 4: It's different since you can set this variable before the prefix is created and additionally you won't need to use a helper script that you have to download on the side to achieve a rather common use case of isolating the home dir folders. I'm not exactly sure if there's a negative to adding a second env variable for isolating the Z: drive, I feel like they should have different variables because they do vastly different things. Both ways feel valid to me, but one is a lot easier to implement
I agree on point 1 to 4, but I did make the same argument and didn't get an answer. But hey, I wouldn't mind having some version of home isolate, so lets hope this MR gets further.