http://bugs.winehq.org/show_bug.cgi?id=22974
Summary: "Shell folders" settings are reset after each wine update Product: Wine Version: 1.2-rc1 Platform: x86 OS/Version: FreeBSD Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: amdmi3@amdmi3.ru
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.
http://bugs.winehq.org/show_bug.cgi?id=22974
--- Comment #1 from Dmitry Timoshkov dmitry@codeweavers.com 2010-05-31 20:36:44 --- You mean that auto-updating the Wine prefix (~/.wine) resets your custom settings?
http://bugs.winehq.org/show_bug.cgi?id=22974
Vitaliy Margolen vitaliy@kievinfo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Severity|normal |minor
http://bugs.winehq.org/show_bug.cgi?id=22974
--- Comment #2 from Dmitry Marakasov amdmi3@amdmi3.ru 2010-06-01 07:43:20 --- Correct, but only these 3 directories are affected. Just checked, My Documents are not being reset.
http://bugs.winehq.org/show_bug.cgi?id=22974
--- Comment #3 from Dmitry Marakasov amdmi3@amdmi3.ru 2010-08-04 12:40:37 --- 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.
http://bugs.winehq.org/show_bug.cgi?id=22974
Gregor Riepl onitake@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |onitake@gmail.com
--- Comment #4 from Gregor Riepl onitake@gmail.com 2012-04-11 11:02:27 CDT --- 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).
http://bugs.winehq.org/show_bug.cgi?id=22974
Vitaliy Margolen vitaliy-bugzilla@kievinfo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever Confirmed|0 |1
--- Comment #5 from Vitaliy Margolen vitaliy-bugzilla@kievinfo.com 2012-04-11 21:25:27 CDT --- Confirming. It only happens when those directories are empty.
https://bugs.winehq.org/show_bug.cgi?id=22974
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download, integration
--- Comment #6 from Austin English austinenglish@gmail.com --- Still in wine-1.7.16-178-g7e874ae
https://bugs.winehq.org/show_bug.cgi?id=22974
Xodetaetl dev@xod.me changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dev@xod.me
https://bugs.winehq.org/show_bug.cgi?id=22974
Rosanne DiMesio dimesio@earthlink.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |shtetldik@gmail.com
--- Comment #7 from Rosanne DiMesio dimesio@earthlink.net --- *** Bug 38994 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=22974
Adam Bolte abolte@systemsaviour.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |abolte@systemsaviour.com
https://bugs.winehq.org/show_bug.cgi?id=22974
--- Comment #8 from Adam Bolte abolte@systemsaviour.com --- Still an issue in wine 1.7.53.
https://bugs.winehq.org/show_bug.cgi?id=22974
--- Comment #9 from Adam Bolte abolte@systemsaviour.com --- Still an issue in 1.9.13.
https://bugs.winehq.org/show_bug.cgi?id=22974
sworddragon2@aol.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sworddragon2@aol.com
--- Comment #10 from sworddragon2@aol.com --- (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.
https://bugs.winehq.org/show_bug.cgi?id=22974
--- Comment #11 from Adam Bolte abolte@systemsaviour.com --- 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.
https://bugs.winehq.org/show_bug.cgi?id=22974
cey.tarik@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |cey.tarik@gmail.com
--- Comment #12 from cey.tarik@gmail.com --- *** Bug 41490 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=22974
hash HASH.DuOrden@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |HASH.DuOrden@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=22974
Nguyen Thai Ngoc Duy pclouds@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |pclouds@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=22974
Ruslan Kabatsayev b7.10110111@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |b7.10110111@gmail.com
--- Comment #13 from Ruslan Kabatsayev b7.10110111@gmail.com --- Still present in wine-2.0-235-g2dd0fb8.
https://bugs.winehq.org/show_bug.cgi?id=22974
--- Comment #14 from Ruslan Kabatsayev b7.10110111@gmail.com --- 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.
https://bugs.winehq.org/show_bug.cgi?id=22974
Svitozar Cherepii razotivs@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |razotivs@gmail.com
--- Comment #15 from Svitozar Cherepii razotivs@gmail.com --- 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.
https://bugs.winehq.org/show_bug.cgi?id=22974
Fincer fincer89@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |fincer89@hotmail.com
https://bugs.winehq.org/show_bug.cgi?id=22974
i.Dark_Templar idarktemplar@mail.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |idarktemplar@mail.ru
--- Comment #16 from i.Dark_Templar idarktemplar@mail.ru --- Created attachment 57727 --> https://bugs.winehq.org/attachment.cgi?id=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.
https://bugs.winehq.org/show_bug.cgi?id=22974
--- Comment #17 from Gregor Riepl onitake@gmail.com --- 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?
https://bugs.winehq.org/show_bug.cgi?id=22974
--- Comment #18 from i.Dark_Templar idarktemplar@mail.ru --- 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.
https://bugs.winehq.org/show_bug.cgi?id=22974
Nikolai Vincent Vaags kujeger@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |kujeger@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=22974
Jens Reyer jre.winesim@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jre.winesim@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=22974
Robert Walker bob.mt.wya@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |bob.mt.wya@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=22974
--- Comment #19 from i.Dark_Templar idarktemplar@mail.ru --- Created attachment 61262 --> https://bugs.winehq.org/attachment.cgi?id=61262 wine-bug-22974-wine3.5.patch
Patch updated for wine-3.5 and later.
https://bugs.winehq.org/show_bug.cgi?id=22974
tokktokk fdsfgs@krutt.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |fdsfgs@krutt.org
https://bugs.winehq.org/show_bug.cgi?id=22974
--- Comment #20 from Shmerl shtetldik@gmail.com --- Are there any plans to upstream this fix, or proposed solution isn't good?
https://bugs.winehq.org/show_bug.cgi?id=22974
--- Comment #21 from Shmerl shtetldik@gmail.com --- Bump.
https://bugs.winehq.org/show_bug.cgi?id=22974
Alistair Leslie-Hughes leslie_alistair@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch
https://bugs.winehq.org/show_bug.cgi?id=22974
muesli4@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |muesli4@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=22974
--- Comment #22 from muesli4@gmail.com --- Is there any news on the issue? Why is the patch not accepted? This has been annoying me for years.
https://bugs.winehq.org/show_bug.cgi?id=22974
--- Comment #23 from Gregor Riepl onitake@gmail.com --- 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.
https://bugs.winehq.org/show_bug.cgi?id=22974
Olivier F. R. Dierick o.dierick@piezo-forte.be changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |o.dierick@piezo-forte.be Keywords|download | See Also| |https://bugs.winehq.org/sho | |w_bug.cgi?id=41668
https://bugs.winehq.org/show_bug.cgi?id=22974
pattietreutel katyaberezyaka@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |katyaberezyaka@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=22974
Alistair Leslie-Hughes leslie_alistair@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |shell32
https://bugs.winehq.org/show_bug.cgi?id=22974
--- Comment #24 from Shmerl shtetldik@gmail.com --- Any update on this?
https://bugs.winehq.org/show_bug.cgi?id=22974
--- Comment #25 from Olivier F. R. Dierick o.dierick@piezo-forte.be --- Created attachment 65280 --> https://bugs.winehq.org/attachment.cgi?id=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.
https://bugs.winehq.org/show_bug.cgi?id=22974
Forest forestcode@ixio.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |forestcode@ixio.org
https://bugs.winehq.org/show_bug.cgi?id=22974
--- Comment #26 from Forest forestcode@ixio.org --- 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.
https://bugs.winehq.org/show_bug.cgi?id=22974
Olivier F. R. Dierick o.dierick@piezo-forte.be changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #65280|0 |1 is obsolete| |
--- Comment #27 from Olivier F. R. Dierick o.dierick@piezo-forte.be --- Created attachment 65285 --> https://bugs.winehq.org/attachment.cgi?id=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.
https://bugs.winehq.org/show_bug.cgi?id=22974
--- Comment #28 from Olivier F. R. Dierick o.dierick@piezo-forte.be --- Created attachment 65286 --> https://bugs.winehq.org/attachment.cgi?id=65286 v2 Patch 2/2 shell32: Create symbolic links rather than directories for specific user shell folders
https://bugs.winehq.org/show_bug.cgi?id=22974
--- Comment #29 from Olivier F. R. Dierick o.dierick@piezo-forte.be --- 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.
https://bugs.winehq.org/show_bug.cgi?id=22974
Xodetaetl dev@xod.me changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|dev@xod.me |
https://bugs.winehq.org/show_bug.cgi?id=22974
Olivier F. R. Dierick o.dierick@piezo-forte.be changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |yanestra@gmail.com
--- Comment #30 from Olivier F. R. Dierick o.dierick@piezo-forte.be --- *** Bug 47971 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=22974
Olivier F. R. Dierick o.dierick@piezo-forte.be changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #65285|0 |1 is obsolete| | Attachment #65286|0 |1 is obsolete| |
--- Comment #31 from Olivier F. R. Dierick o.dierick@piezo-forte.be --- Created attachment 66115 --> https://bugs.winehq.org/attachment.cgi?id=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.
https://bugs.winehq.org/show_bug.cgi?id=22974
--- Comment #32 from Shmerl shtetldik@gmail.com --- Is there any plan to review this?
https://bugs.winehq.org/show_bug.cgi?id=22974
--- Comment #33 from Matteo Bruni matteo.mystral@gmail.com --- (In reply to Shmerl from comment #32)
Is there any plan to review this?
Patches generally aren't reviewed or pulled from bugs, no.
https://bugs.winehq.org/show_bug.cgi?id=22974
--- Comment #34 from Shmerl shtetldik@gmail.com --- (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?
https://bugs.winehq.org/show_bug.cgi?id=22974
--- Comment #35 from Ruslan Kabatsayev b7.10110111@gmail.com --- (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 .
https://bugs.winehq.org/show_bug.cgi?id=22974
--- Comment #36 from Shmerl shtetldik@gmail.com --- @Olivier F. R. Dierick: See above, can you please submit the patch to the mailing list?
https://bugs.winehq.org/show_bug.cgi?id=22974
Olivier F. R. Dierick o.dierick@piezo-forte.be changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |rencer@euromail.hu
--- Comment #37 from Olivier F. R. Dierick o.dierick@piezo-forte.be --- *** Bug 48365 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=22974
--- Comment #38 from Shmerl shtetldik@gmail.com --- (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?
https://bugs.winehq.org/show_bug.cgi?id=22974
--- Comment #39 from Olivier F. R. Dierick o.dierick@piezo-forte.be --- 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.
https://bugs.winehq.org/show_bug.cgi?id=22974
Olivier F. R. Dierick o.dierick@piezo-forte.be changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |2aad95254c19df21fc0f7c4413c | |a3874c8d87997 Resolution|--- |FIXED Status|NEW |RESOLVED
--- Comment #40 from Olivier F. R. Dierick o.dierick@piezo-forte.be --- Hello,
Should be fixed by commit 2aad95254c19df21fc0f7c4413ca3874c8d87997.
Regards.
https://bugs.winehq.org/show_bug.cgi?id=22974
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #41 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 5.3.