http://bugs.winehq.org/show_bug.cgi?id=12914
Summary: wineprefixcreate overrides custom entries in Explorer\Shell Folders Product: Wine Version: 0.9.59. Platform: Other OS/Version: other Status: UNCONFIRMED Severity: minor Priority: P2 Component: tools AssignedTo: wine-bugs@winehq.org ReportedBy: aelschuring@hotmail.com
I have been playing with specifying custom paths for user shell folders, in order to be able to use the same wineprefix for multiple users (r/o C: drive, r/w D:). But it seems that every time I run wineprefixcreate, it overrides some of the paths specified in [Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders].
I'll shorten this up for brevity: arno@master:~$ wine --version wine-0.9.59 arno@master:~$ rm -fr .wine arno@master:~$ wineprefixcreate Could not load Mozilla. HTML rendering will be disabled. /home/arno/.wine updated successfully. arno@master:~$ grep '\profiles\' .wine/user.reg "AppData"="C:\windows\profiles\arno\Application Data" "Cookies"="C:\windows\profiles\arno\Cookies" "Desktop"="C:\windows\profiles\arno\Desktop" "Favorites"="C:\windows\profiles\arno\Favorites" "History"="C:\windows\profiles\arno\Local Settings\History" arno@master:~$ sed -i 's/(\profiles\\)arno/\1test/' .wine/user.reg arno@master:~$ grep '\profiles\' .wine/user.reg "AppData"="C:\windows\profiles\test\Application Data" "Cookies"="C:\windows\profiles\test\Cookies" "Desktop"="C:\windows\profiles\test\Desktop" "Favorites"="C:\windows\profiles\test\Favorites" "History"="C:\windows\profiles\test\Local Settings\History" arno@master:~$ wineprefixcreate Could not load Mozilla. HTML rendering will be disabled. /home/arno/.wine updated successfully. arno@master:~$ grep '\profiles\' .wine/user.reg "AppData"="C:\windows\profiles\arno\Application Data" "Cookies"="C:\windows\profiles\arno\Cookies" "Desktop"="C:\windows\profiles\test\Desktop" "Favorites"="C:\windows\profiles\test\Favorites" "History"="C:\windows\profiles\arno\Local Settings\History"
Also, the overrides that are displayed here do not come from userdef.reg (tested by modifying userdef.reg), they appear to be coming directly from [Software\Microsoft\Windows NT\CurrentVersion\ProfileList]\"ProfilesDirectory"
I'm not sure what the intended behaviour of wineprefixcreate should be (I think it should not modify existent keys, only add missing ones), but at least the inconsistent behaviour is a bug.
http://bugs.winehq.org/show_bug.cgi?id=12914
Vitaliy Margolen vitaliy@kievinfo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Severity|minor |major Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Target Milestone|--- |1.0.0
--- Comment #1 from Vitaliy Margolen vitaliy@kievinfo.com 2008-05-02 09:51:09 --- Confirming. This shouldn't happen. Needs to be fixed before 1.0.0
http://bugs.winehq.org/show_bug.cgi?id=12914
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID
--- Comment #2 from Alexandre Julliard julliard@winehq.org 2008-05-06 05:06:00 --- The Shell Folders values are expanded on-demand from the User Shell Folders ones. If you want to change them you have the change the latter not the former.
http://bugs.winehq.org/show_bug.cgi?id=12914
--- Comment #3 from Arno Schuring aelschuring@hotmail.com 2008-05-09 14:14:23 --- (In reply to comment #2)
The Shell Folders values are expanded on-demand from the User Shell Folders ones. If you want to change them you have the change the latter not the former.
Ok, thanks. I accept that explanation. But how about the inconsistencies reported in the last step?
For example, if I change both the "Desktop" and "Cookies" entries in the User Shell Folders, the Cookies entry in Shell Folders gets modified while the Desktop entry remains unchanged.
http://bugs.winehq.org/show_bug.cgi?id=12914
--- Comment #4 from Arno Schuring aelschuring@hotmail.com 2008-05-09 14:18:08 --- (In reply to comment #3)
(In reply to comment #2)
The Shell Folders values are expanded on-demand from the User Shell Folders ones. If you want to change them you have the change the latter not the former.
I believe I misunderstood the "on-demand" portion of your statement. Am I correct in assuming that wineprefixcreate only touches a few of the keys in Shell Folders, and that the other keys will get expanded only when (and as soon as) an application accesses them?
http://bugs.winehq.org/show_bug.cgi?id=12914
--- Comment #5 from Alexandre Julliard julliard@winehq.org 2008-05-09 15:23:17 --- (In reply to comment #4)
I believe I misunderstood the "on-demand" portion of your statement. Am I correct in assuming that wineprefixcreate only touches a few of the keys in Shell Folders, and that the other keys will get expanded only when (and as soon as) an application accesses them?
Yes, exactly. A few get updated during wineprefixcreate because they are used during the registration of some dlls. The others will be updated once an app uses them.
It would certainly be possible to make the registration of shell32 update all of them if you feel like doing that.
http://bugs.winehq.org/show_bug.cgi?id=12914
Julien Goodwin winehq@studio442.com.au changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |winehq@studio442.com.au
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #6 from Julien Goodwin winehq@studio442.com.au 2008-06-18 09:27:41 --- OK, I fail to see how this is resolved. I'm needing to do a similar thing to the submitter.
If this bug is INVALID then what do I do so that Windows apps see a shell folder as "d:\blah". I specifically can't just point to the same filesystem location due to some app level stupidities.
--- Comment #7 from Austin English austinenglish@gmail.com 2008-09-10 13:25:02 --- Closing invalid.