Incorrect filepaths returned in programs run by Wine

[savalas]

Yesterday I updated Wine from 1.3.2 to 1.3.3 and today when I wanted to use a program through Wine (a text editor, but it doesn't really matter) I received an error that some files could not be found. The filepath given in the error message was wrong, instead of reading something like /home/user/.wine/foo/bar it was /home᐀/user᐀/.wine᐀/foo᐀/bar᐀ (this is not the actual path as I couldn't select the error message.) Using the file selector, I could find that filenames contained some junk at the end. Upon further inspection, I found that 3 bytes are appended to each filename and those bytes correspond to the type of entry, specifically:

• e1a080 - file
  
• e18880 - dir
  
• e19080 - mount point

Now I'm kind of stuck because I have no idea on how to solve that problem. I have tried to downgrade to Wine 1.3.2 but now the same problem occurs. I have tried to wipe my .wine dir and start anew, without success. I have to assume that the problem is not in Wine 1.3.3 but rather in some dependency that got upgraded between the first time I compiled Wine 1.3.2 and yesterday when I compiled 1.3.3. I have taken a look into /var/log/emerge.log but I have emerged/upgraded dozens of packages since then and I couldn't guess what package could be responsible for this anyway. Any help would be appreciated.

I'm on ~amd64 and most if not all of my system was compiled using GCC 4.5.[0-1] (including my last working configuration). I'm considering emerge -e @world with GCC 4.4.4-r2 as a last resort if nothing else works.

Thanks for any help.

Edit: tried downgrading Wine to 1.1.44, 1.2.0, 1.3.0, tried downgrading dbus from 1.4.0 to 1.2.24-r2, yasm from 1.1.0 to 1.0.1, all without success. Since merely recompiling Wine broke it, I have to assume that my problem is with a package used at compilation time, something that would have been updated between the last working compilation and yesterday but I can't find any good candidate in my emerge.log.

[BradN]

Just to help narrow the problem, try renaming your .wine folder and letting it make a fresh one, this will narrow the problem from possibly being in wine's profile.

Failing that, I'd recommend starting an emerge -e world just to completely refresh all the library linking. If that doesn't help, then there's almost certainly a bug somewhere.

[savalas]

Yeah, I've tried nuking my .wine folder (rm -rf ~/.wine) and let Wine rebuild one, but that didn't do anything. I've found something dumbfoundingly interesting though:

Here's what winecfg's "Desktop Integration" tab looks like on a fresh user.

The file selector shows the incorrect dir names (as expected) and somehow the virtual folders "My Pictures" and others contain the same kind of junk. That last part confuses me to no end. I've checked the various registry entries in user.reg and userdef.reg and the names are fine. Up till then I thought the problem was somewhere between the actual filesystem and Wine's virtual filesystem, but that shouldn't affect paths that are taken straight from the registry.

[BradN]

I'm not sure what libraries handle character set conversion. I think that may be a part of glibc? I would suspect that package anyway because it probably handles low level (well, ok, mid-level) directory reading.

Try rebuilding glibc and see if it helps. Otherwise ldd the wine executable and see what all libraries it pulls in, suspect anything that's not obviously used for something else.

[hiziki_gard]

I can confirm this problem as I got the same garbage code appended to end of my directories.

So far I haven't had luck in figuring out the solution.
_________________
default-linux/amd64/2007.0, gcc-4.2.3, glibc-2.7-r2, 2.6.25-hh5 x86_64

[savalas]

[BradN]

D'oh, I forgot wine dynamically loads all of its dll's, so ldd would maybe be more useful on kernel32 I think (or maybe even a different dll, I'm not sure if directory reading is abstracted further in windows)

[savalas]

As it turns out, this bug actually affects a bunch of people.

[BradN]

Whoever applied that patch and neglected to bump the revisions should be smacked upside the head. That's the whole point of the revisions.

I can understand _maybe_ a trivial build system patch might be done without bumping the revision, but the compiled code generated should always be identical in such a case.