Every wine update re-enables desktop integration links

[Gregor Riepl]

Whenever the wine1.3 package is updated, wine reconfigures certain things when it is launched the next time.

This reconfiguration step relinks the My Pictures, My Music and My Videos to the respective folders in the user's home directory, even if they were disabled before.

As I do not want that, it's annoying that I have to run winecfg after every update and disable the links manually.

wine should be a bit smarter about that and not enable the links if they were disabled before, I think.

[Dmitry Marakasov (amdmi3)]

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.

[Dmitry-baikal (dmitry-baikal)]

You mean that auto-updating the Wine prefix (~/.wine) resets your custom
settings?

[Dmitry Marakasov (amdmi3)]

Correct, but only these 3 directories are affected. Just checked, My Documents are not being reset.

[Dmitry Marakasov (amdmi3)]

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.

[Gregor Riepl (onitake)]

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).

[Vitaliy-bugzilla (vitaliy-bugzilla)]

Confirming. It only happens when those directories are empty.

[Austin English (austinenglish)]

Still in wine-1.7.16-178-g7e874ae

[Dimesio (dimesio)]

*** Bug 38994 has been marked as a duplicate of this bug. ***

[Adam Bolte (boltronics)]

Still an issue in wine 1.7.53.

[Adam Bolte (boltronics)]

Still an issue in 1.9.13.

[Removed by request (removed3425744)]

(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.

[Adam Bolte (boltronics)]

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.

[Stefan Heimersheim (stefan-heimersheim)]

I can confirm what #12 replied to #3,
This makes the bug more important because there is no longer a workaround.

[Cey-tarik (cey-tarik)]

*** Bug 41490 has been marked as a duplicate of this bug. ***

[Ruslan (b7-10110111)]

Still present in wine-2.0-235-g2dd0fb8.

[Ruslan (b7-10110111)]

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.

[Razotivs (razotivs)]

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.

[Idarktemplar (idarktemplar)]

Created attachment 57727
wine-bug-22974.patch

I've made small patch which fixed issue to me. I've tested it using wine-2.3 from Gentoo.

[Gregor Riepl (onitake)]

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?

[Idarktemplar (idarktemplar)]

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.

[Idarktemplar (idarktemplar)]

Created attachment 61262
wine-bug-22974-wine3.5.patch

Patch updated for wine-3.5 and later.

[Shmerl (shmerl1)]

Are there any plans to upstream this fix, or proposed solution isn't good?

[Shmerl (shmerl1)]

Bump.

[Moritz Bruder (muesli4-2)]

Is there any news on the issue? Why is the patch not accepted? This has been annoying me for years.

[Gregor Riepl (onitake)]

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.

[Shmerl (shmerl1)]

Any update on this?

[Olivier Dierick (o-dierick)]

Created attachment 65280
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.

[Forest (foresto)]

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.

[Olivier Dierick (o-dierick)]

Created attachment 65285
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.

[Olivier Dierick (o-dierick)]

Created attachment 65286
v2 Patch 2/2 shell32: Create symbolic links rather than directories for specific user shell folders

[Olivier Dierick (o-dierick)]

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.

[Olivier Dierick (o-dierick)]

*** Bug 47971 has been marked as a duplicate of this bug. ***

[Olivier Dierick (o-dierick)]

Created attachment 66115
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.

[Shmerl (shmerl1)]

Is there any plan to review this?

[Matteo-mystral (matteo-mystral)]

(In reply to Shmerl from comment #32)
> Is there any plan to review this?

Patches generally aren't reviewed or pulled from bugs, no.

[Shmerl (shmerl1)]

(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?

[Ruslan (b7-10110111)]

(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 .

[Shmerl (shmerl1)]

@Olivier F. R. Dierick: See above, can you please submit the patch to the mailing list?

[Olivier Dierick (o-dierick)]

*** Bug 48365 has been marked as a duplicate of this bug. ***

[Shmerl (shmerl1)]

(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?

[Olivier Dierick (o-dierick)]

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.

[Olivier Dierick (o-dierick)]

Hello,

Should be fixed by commit 2aad95254c19df21fc0f7c4413ca3874c8d87997.

Regards.

[Alexandre Julliard (julliard)]

Closing bugs fixed in 5.3.