If you delete .wine on a 64-bit system, and then execute a Windows app to cause Wine to rebuild it, drive_c contains only a windows subdirectory which itself has system and syswow64 subdirectories. There are no "Program Files" or "Program Files (x86)" subdirectories, and the registry has no "ProgramFilesDir" and "CommonFilesDir" values set. This prevents most windows apps from installing. This is a pretty recent change, as this was not happening a month ago. Neither did we get a syswow64 directory, so I'm guessing that this is some sort of configuration choice.
Hi, thanks for reporting this bug. As there is no maintainer for this package I added the committers in CC. (The Wine development release 1.3.34 is available.) (Please set the status to 'assigned' if you are working on it)
CC: (none) => anssi.hannula, dmorganec, fundawang, lists.jjorgeSource RPM: wine64-1.3.34-1.mga2.x86_64.rpm => wine
I couldn't reproduce it here. Maybe it is because I runned winecfg, but both 32 and 64 winecfg created Program Files (or Program Files (x86))
CC: (none) => sfietkonstantin
This doesn't reproduce reliably. It will fail repeatedly, and I'll leave it for a couple of weeks (with intervening updates), and all of a sudden it will work. OTOH, I don't usually run winecfg explicitly until this has actually worked (and then to redefine the D-disk). So it could be that winecfg invoked explicitly is doing something that just invoking a wine app with uninitialized directories doesn't. I know something's wrong here, but I hven't the faintest idea of how to debug it. If you can suggest logging or debugging steps, I can beat on it until it reproduces.
I think I've found the key. The problem occurs if you do a rm -fR .wine/* and then do something that should cause Wine to rebuild the .wine directory infrastructure. If you do rm -fR .wine mkdir .wine and the do the same thing, it works. Something, probably the wine server, is retaining a link to the .wine directory and some sort of cached contents which survives the first rm.
CC: lists.jjorge => (none)
Assignee: bugsquad => supp
Hi, This bug was filed against cauldron, but we do not have cauldron at the moment. Please report whether this bug is still valid for Mageia 2. Thanks :) Cheers, marja
Keywords: (none) => NEEDINFO
Keywords: NEEDINFO => (none)Whiteboard: (none) => MGA2TOO
Resetting assignee to bugsquad as I no longer maintain this package...
Assignee: supp => bugsquad
Seems to be a wine bug and nothing related to package. Did you reported it upstream? Do you still reproduce in cauldron?
Status: NEW => ASSIGNEDCC: (none) => mageiaAssignee: bugsquad => mageia
I can still reproduce it in Cauldron. Download DVDCopy from http://www.dvdfab.com , install it in a fresh .wine directory, i. e. delete the current one and do a "mkdir .wine". The install will put up a dialog about "updating your wine configuration", and then complete normally. Now do "rm -fR .wine/*" and try the install again. You'll get no "Updating..." dialog. You'll get the language prompt from the DVDFab install, and then an immediate error saying that the 64-bit Program Files directory can't be found. I did not report it upstream. If you have a URL for the wine bugtracker, I'll be happy to.
Ok, so it's not a packaging issue. Thanks for your test Frank. I advise you to report it here: http://bugs.winehq.org/ But I think they will answer you it's a bug from your side as it seems logical, if you delete directory content, no to be able to work as expected. I'm closing bug here. Thanks!
Status: ASSIGNED => RESOLVEDResolution: (none) => INVALID
Found the specific cause. Wince creates a file in .wine called ".update-timestamp" which is not deleted by the "rm -fR .wine/*". That file being present is what causes the problem. If I delete it manually, the reproducible case works fine. Not sure whether this is worth reporting or not.