WineHQ
Bug Tracking Database – Bug 22974

 Bugzilla

 

Last modified: 2020-02-28 13:57:05 UTC  

"Shell folders" settings are reset after each wine update

Bug 22974 - "Shell folders" settings are reset after each wine update
"Shell folders" settings are reset after each wine update
Status: CLOSED FIXED
AppDB: Show Apps affected by this bug
Product: Wine
Classification: Unclassified
Component: shell32
1.2-rc1
x86 FreeBSD
: P2 minor
: ---
Assigned To: Mr. Bugs
: integration, patch
: 38994 41490 47971 48365 (view as bug list)
Depends on:
Blocks:
  Show dependency tree
 
Reported: 2010-05-31 11:02 UTC by Dmitry Marakasov
Modified: 2020-02-28 13:57 UTC (History)
21 users (show)

See Also:
Regression SHA1:
Fixed by SHA1: 2aad95254c19df21fc0f7c4413ca3874c8d87997
Distribution: ---
Staged patchset:


Attachments
wine-bug-22974.patch (4.15 KB, patch)
2017-03-29 05:06 UTC, i.Dark_Templar
Details | Diff
wine-bug-22974-wine3.5.patch (4.65 KB, patch)
2018-04-30 00:52 UTC, i.Dark_Templar
Details | Diff
Patchset for wine 4.15 (4.69 KB, application/x-bzip)
2019-09-22 01:53 UTC, Olivier F. R. Dierick
Details
v2 Patch 1/2 shell32: Move and split _SHCreateSymbolicLinks() (24.48 KB, patch)
2019-09-23 22:55 UTC, Olivier F. R. Dierick
Details | Diff
v2 Patch 2/2 shell32: Create symbolic links rather than directories for specific user shell folders (5.58 KB, patch)
2019-09-23 22:56 UTC, Olivier F. R. Dierick
Details | Diff
Proposed patchset v2 updated for wine-5.0-rc2 (5.57 KB, application/x-bzip)
2019-12-27 12:49 UTC, Olivier F. R. Dierick
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Dmitry Marakasov 2010-05-31 11:02:29 UTC
Althrough I've disabled shell folder links (My Pictures, My Music, My Videos, My Documents) by unchecking "Link to" checkbox for each of them in winecfg->Desktop Integration->Shell Folders, after each wine update those settings are reset and all folders are again linked to my home directory. That is highly undesirable, as I'd prefer windows apps never access anything outside .wine/drive_c.
Comment 1 Dmitry Timoshkov 2010-05-31 20:36:44 UTC
You mean that auto-updating the Wine prefix (~/.wine) resets your custom
settings?
Comment 2 Dmitry Marakasov 2010-06-01 07:43:20 UTC
Correct, but only these 3 directories are affected. Just checked, My Documents are not being reset.
Comment 3 Dmitry Marakasov 2010-08-04 12:40:37 UTC
Addendum: folders are reset to ~ only if I uncheck "Link to" for them. If they are linked to any directory, this is preserved as it should.
Comment 4 Gregor Riepl 2012-04-11 11:02:27 UTC
This bug affects other platforms too.
I can confirm the same behavior on wine 1.3 and 1.4 on Ubuntu 11.10 (using the official PPA).
Comment 5 Vitaliy Margolen 2012-04-11 21:25:27 UTC
Confirming. It only happens when those directories are empty.
Comment 6 Austin English 2014-04-16 00:44:49 UTC
Still in wine-1.7.16-178-g7e874ae
Comment 7 Rosanne DiMesio 2015-08-31 21:16:55 UTC
*** Bug 38994 has been marked as a duplicate of this bug. ***
Comment 8 Adam Bolte 2015-10-17 20:27:15 UTC
Still an issue in wine 1.7.53.
Comment 9 Adam Bolte 2016-06-25 06:26:53 UTC
Still an issue in 1.9.13.
Comment 10 sworddragon2 2016-08-23 18:31:32 UTC
(In reply to Dmitry Marakasov from comment #2)
> Correct, but only these 3 directories are affected. Just checked, My
> Documents are not being reset.

On upgrading Wine to version 1.9.17 (not sure if some versions earlier are affected by the changed behavior too) all 5 directories got reset to the default value.


(In reply to Dmitry Marakasov from comment #3)
> Addendum: folders are reset to ~ only if I uncheck "Link to" for them. If
> they are linked to any directory, this is preserved as it should.

To make the above even worse the directories are now even reset if they are symlinks.
Comment 11 Adam Bolte 2016-08-23 18:46:01 UTC
For as long as I can remember, I always have to run winecfg, navigate to Desktop Integration, and untick "Link to" for every path whenever I load a new Wineprefix after changing Wine builds. I vaguely recall that even just applying a patch seems to cause your customisations getting overridden.

This is currently the most annoying bug in Wine that's not compatibility-related.
Comment 12 cey.tarik 2016-10-11 16:32:55 UTC
*** Bug 41490 has been marked as a duplicate of this bug. ***
Comment 13 Ruslan Kabatsayev 2017-02-01 01:13:29 UTC
Still present in wine-2.0-235-g2dd0fb8.
Comment 14 Ruslan Kabatsayev 2017-02-01 07:04:21 UTC
A workaround for this is to use the following command after you set up your links:

chmod -w ~/.wine/drive_c/users/`whoami`/

This at least prevents any changes by wineboot or whoever to these links after upgrade.
Comment 15 razotivs 2017-02-01 10:22:17 UTC
While this is useful on first run, there should be some form of protection (like check registry key that is set after first run) established in dlls/shell32/shellpath.c to not do this over and over again.
Comment 16 i.Dark_Templar 2017-03-29 05:06:58 UTC
Created attachment 57727 [details]
wine-bug-22974.patch

I've made small patch which fixed issue to me. I've tested it using wine-2.3 from Gentoo.
Comment 17 Gregor Riepl 2017-03-29 12:21:27 UTC
Thanks for the patch!

A few comments on the code:

                     strcpy(szMyStuffTarget, szPersonalTarget);
                     if (_SHAppendToUnixPath(szMyStuffTarget, MAKEINTRESOURCEW(aidsMyStuff[i])))
-                        mkdir(szMyStuffTarget, 0777);
+                        mkdir(szMyStuffTarget, 0755);

(similar lines follow)

Are you sure that you want to circumvent the umask?
In most environments, the group and owner write bits are masked out anyway, and sometimes users might have set a less restrictive umask. This mode will prevent that, and I don't think it is relevant to the issue anyway.

There seem to be some whitespace issues as well.

And where is _SHCreateSymbolicLinks defined?
Comment 18 i.Dark_Templar 2017-03-29 15:24:42 UTC
The function '_SHCreateSymbolicLinks' already exists in master branch, it's defined around line 4250. And originally it was called around line 5961. It's the function that currently reinitializes those "shell folders" in question.

This function is called during registry of shell32.dll, which happens on each wine upgrade/reinstall or when 'wineboot -u' is called. Issue is caused by function SHGetFolderPathAndSubDirW being called for some of shell folders with flag CSIDL_FLAG_CREATE before function _SHCreateSymbolicLinks is called. Thus, when function _SHCreateSymbolicLinks is called, some directories, like Desktop or My documents, may already exist. To overcome that issue and initialize shell folders by proper links, current code just removes current shell folders, and reinitializes them to default locations. And it looks like it only removes current shell folders if they're symlinks or empty directories. This causes the current issue.

The proposed registry key solution may circumvent the issue by not allowing the function _SHCreateSymbolicLinks to run on prefix upgrade and remove current symlinks. My patch uses different approach. Instead of removing directories after they're created and recreating them, right before shell directory is being created in function SHGetFolderPathAndSubDirW (which shouldn't happen too often) the initial symlinks setup is performed to make sure that shell folders are properly set up.

Since _SHCreateSymbolicLinks calls function SHGetFolderPathAndSubDirW via function SHGetFolderPathW I had to remove flag CSIDL_FLAG_CREATE from calls in that function and correspondingly modify return code checks. Otherwise it'd cause infinite recursion and finally a crash. Well, creation of directory is not what is desired at that point anyway, just it's path is needed.

I prefer tabs over spaces for identation, due to that my editors are set up to ident with tabs, and it looks like I added some lines with them. As for directory permissions, I just made them what is usually proposed as safe defaults.

Please feel free to modify any parts of patch you think should be modified or use different approach entirely if you think this one is undesired.
Comment 19 i.Dark_Templar 2018-04-30 00:52:43 UTC
Created attachment 61262 [details]
wine-bug-22974-wine3.5.patch

Patch updated for wine-3.5 and later.
Comment 20 Shmerl 2018-12-18 22:39:16 UTC
Are there any plans to upstream this fix, or proposed solution isn't good?
Comment 21 Shmerl 2019-01-17 22:45:54 UTC
Bump.
Comment 22 muesli4 2019-01-19 21:30:27 UTC
Is there any news on the issue? Why is the patch not accepted? This has been annoying me for years.
Comment 23 Gregor Riepl 2019-01-21 13:54:37 UTC
Probably because the patch hasn't been shaped up, approved and sponsored by someone with commit rights...

I still stand by my comment about modifying the permission mask:
Applications should _not_ preclude any umask set by the user or the system. A directory should be created with 0777 permissions - in most cases this will translate to 0755 due to a suitable 0022 umask. In all other cases, it is wrong to go against the user's wishes and set more restrictive permissions.

If you really think it's necessary to do just that, please move the permission modification to a different patch, as it doesn't contribute to solving the bug here.

Aside from that, I think the patch should be tested thoroughly and accepted.
Comment 24 Shmerl 2019-09-20 12:07:59 UTC
Any update on this?
Comment 25 Olivier F. R. Dierick 2019-09-22 01:53:39 UTC
Created attachment 65280 [details]
Patchset for wine 4.15

Hello,

The attached file is a patchset and this is a request for comments.

The patchset aims at retaining userdirs symlink/real directories across updates.

It is different from the other proposed patch in that it only creates one symlink when looking for a specific folder.

On prefix creation, the default is still to create symlinks.
If the user unticks the links in winecfg, he gets real directories in the wineprefix. With the patchset, they are retained across updates.

I made a small modification to the 'educated guess' that is used to chose the target of the symlinks:

The old behavior did target the PICTURE, VIDEO and MUSIC symlinks to subdirs of PERSONAL (=My Documents) if they did exists, wherever the PERSONAL folder target to ($HOME/My Documents, XDG documents dir, OSX documents path, '$HOME' or %USERPROFILE%).

The new behavior is that it does that only when PERSONAL really comes from '$HOME/My Documents', no more when PERSONAL comes from XDG or OS X.
XDG and OS X will use the separate PICTURE, VIDEO and MUSIC settings that they define and fallback to PERSONAL if necessary.

I think that people that have setup XDG or use OSX paths want the feature to be consistent for all the folder.

If that change is undesirable, I may provide another patchset with original behavior.

Regards.
Comment 26 Forest 2019-09-23 14:57:38 UTC
Olivier, thank you. Getting rid of the remove() call looks like it would fix the annoyance of having My Documents relocated every time I upgrade wine or dxvk.
Comment 27 Olivier F. R. Dierick 2019-09-23 22:55:11 UTC
Created attachment 65285 [details]
v2 Patch 1/2 shell32: Move and split _SHCreateSymbolicLinks()

Hello,

Here is a new patchset that I think is cleaner.
I changed my mind and don't touch anything but the issue.
I think it will help getting the patchset approved sooner.
Other features deserve their own enhancement bugs anyway.

Patch 1/2:
- Splits the _SHCreateSymbolicLinks() into folder type-specific functions, keeping the old logic intact. This way the different folders can be handled separately.
- It also fixes some trailing whitespace in the moved code but that's negligible.

Patch 2/2:
- Adds a helper function that creates a single symbolic link at a time, for the folders we are interested in.
- Calls the helper function where the old code did only create a directory.
- Disables the removal of existing symlinks/directories, in the symlink creation functions.
- Also says to not create the folder when looking up for its path for the symlink, to avoid an infinite loop.

Note that the winecfg code handles the folder symlink/directory switching itself, removing the symlink/directory as appropriate. It even makes a backup of the directory when switching to a symlink and restores it when switching back. The removal of the remove() calls doesn't affect the ability to manage the shell folders through the winecfg UI.

Please, test the patchset thoroughly on your system and give feedback if it breaks anything.
Meanwhile, I'll request for comments on the developer mailing list.

Regards.
Comment 28 Olivier F. R. Dierick 2019-09-23 22:56:54 UTC
Created attachment 65286 [details]
v2 Patch 2/2 shell32: Create symbolic links rather than directories for specific user shell folders
Comment 29 Olivier F. R. Dierick 2019-10-04 11:18:14 UTC
Hello,

Proposed patchset applies cleanly on top of wine 4.17.

No replies to my request for comment on wine-devel mailing list yet.

Regards.
Comment 30 Olivier F. R. Dierick 2019-12-27 12:34:07 UTC
*** Bug 47971 has been marked as a duplicate of this bug. ***
Comment 31 Olivier F. R. Dierick 2019-12-27 12:49:14 UTC
Created attachment 66115 [details]
Proposed patchset v2 updated for wine-5.0-rc2

Hello,

Proposed patchset rebased for wine 5.0-rc2.
shell32 - Preserve Custom Userdirs.

- You get 'real' directories by unticking in winecfg.
- You get a symlink by ticking in winecfg.
- Or you can manage the dir/symlink yourself in the prefix and winecfg will use that.
- Switching between dir/symlink will backup/restore 'real' directory.


With proposed patch, default trying-to-be-smart symlinks will be created only if there is no directory or symlink for an individual shell folder in the prefix. Otherwise the existing dir or symlink will be preserverd.

v2 : Updated for DOWNLOADS and TEMPLATES.

Please, test and give feedback for your individual use case.

Regards.
Comment 32 Shmerl 2020-01-18 20:59:21 UTC
Is there any plan to review this?
Comment 33 Matteo Bruni 2020-01-30 07:36:12 UTC
(In reply to Shmerl from comment #32)
> Is there any plan to review this?

Patches generally aren't reviewed or pulled from bugs, no.
Comment 34 Shmerl 2020-01-30 09:25:34 UTC
(In reply to Matteo Bruni from comment #33)
> (In reply to Shmerl from comment #32)
> > Is there any plan to review this?
> 
> Patches generally aren't reviewed or pulled from bugs, no.

So where are they pulled from?
Comment 35 Ruslan Kabatsayev 2020-01-30 09:35:15 UTC
(In reply to Shmerl from comment #34)
> So where are they pulled from?

From the wine-devel mailing list. See https://wiki.winehq.org/Submitting_Patches .
Comment 36 Shmerl 2020-01-30 10:01:07 UTC
@Olivier F. R. Dierick: See above, can you please submit the patch to the mailing list?
Comment 37 Olivier F. R. Dierick 2020-02-16 10:32:37 UTC
*** Bug 48365 has been marked as a duplicate of this bug. ***
Comment 38 Shmerl 2020-02-16 12:05:56 UTC
(In reply to Olivier F. R. Dierick from comment #37)
> *** Bug 48365 has been marked as a duplicate of this bug. ***

Hi Olivier! Did you have a chance to submit your patch to the mailing list?
Comment 39 Olivier F. R. Dierick 2020-02-16 18:42:26 UTC
Hello,

(In reply to Shmerl from comment #38)
> Hi Olivier! Did you have a chance to submit your patch to the mailing list?

I rebased on 5.2 and sent the patches to the mailing list.

Regards.
Comment 40 Olivier F. R. Dierick 2020-02-21 00:11:37 UTC
Hello,

Should be fixed by commit 2aad95254c19df21fc0f7c4413ca3874c8d87997.

Regards.
Comment 41 Alexandre Julliard 2020-02-28 13:57:05 UTC
Closing bugs fixed in 5.3.


Privacy Policy
If you have a privacy inquiry regarding this site, please write to [email protected]

Hosted By CodeWeavers