| Summary: | Wine is not creating Program Files directories | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | Frank Griffin <ftg> |
| Component: | RPM Packages | Assignee: | Damien Lallement <mageia> |
| Status: | RESOLVED INVALID | QA Contact: | |
| Severity: | normal | ||
| Priority: | Normal | CC: | anssi.hannula, dmorganec, fundawang, mageia, sfietkonstantin |
| Version: | Cauldron | ||
| Target Milestone: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | MGA2TOO | ||
| Source RPM: | wine | CVE: | |
| Status comment: | |||
|
Description
Frank Griffin
2011-12-15 18:23:38 CET
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.jjorge 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.
José Jorge
2012-01-24 13:09:22 CET
CC:
lists.jjorge =>
(none)
Remco Rijnders
2012-02-18 10:25:15 CET
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
Frank Griffin
2012-06-12 21:33:32 CEST
Keywords:
NEEDINFO =>
(none) 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 =>
ASSIGNED 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 =>
RESOLVED 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. |