[Bug 52732] New: Garbage user-name crated with wine, not the proper user-name like in older versions.
https://bugs.winehq.org/show_bug.cgi?id=52732
Bug ID: 52732 Summary: Garbage user-name crated with wine, not the proper user-name like in older versions. Product: Wine Version: 7.4 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: rencer@euromail.hu Distribution: ---
I'm not sure exactly when (the latest 7.4 version or which previous version) this started to happen, because for a very long time I used Lutris to manage Wine-versions and my Windows programs. Because of Lutris,I don't even have Wine installed system-wide.
Sadly with the newest system (Manjaro XFCE) update someting in Python is totally broken, and because of that Lutris won't work anymore, so I had to install wine from system repo. The latest version in 7.4
The problem is when I createa a new (or try to change an existing wineprefix to use this system version), the user name is not my real username that I logged in with. Now wine creates a strange garbage user name: "u@". Previously it was correct and alway created the proper user folder, with the user who logged in and run wine.
Long time ago, before I started using Lutris (I'm not sure which wine version that was, around 4.x) I used command line to run wine, create prefixes, or run any Windows programs and never was this bug. Also most of the progrmas I installed with older versions and later never changed it, I think the last version that I used with Lutris is 6.something and it also don't had this user-name bug.
Problem is that all programs in any existing Wine-prefixes that was created with Lutris, (with the PROPER user-name) are broken, settings are lost, saves won't find, etc.,etc.,etc. because all the settings/saves are located in the correct user-name folder and not in this new bugged garbage "@u" name. First I thouth I lost all my files, and when I checked them with file-manager, that is how I realised this strange behaviour.
Copying the files to the new garbage name location in NOT working all the time, because many times programs store their settings, saved files, etc. in the registry-database, so, this bug really broke many things.
https://bugs.winehq.org/show_bug.cgi?id=52732
Rencer rencer@euromail.hu changed:
What |Removed |Added ---------------------------------------------------------------------------- Severity|normal |major
https://bugs.winehq.org/show_bug.cgi?id=52732
--- Comment #1 from Rafał Mużyło galtgendo@o2.pl --- ...that doesn't sound like a wine problem, but 'I've got a mess on my system' problem...(especially given that 'something in Python is totally broken' bit)
output of 'env | sort' ?
https://bugs.winehq.org/show_bug.cgi?id=52732
--- Comment #2 from Rencer rencer@euromail.hu --- Lutris and python has nothing to do with the Wine problem that I write about. Please read again what I wrote. It is there what is the bug with Wine, it's not about Lutris (or python) isn't working as it worked before the system-update. That thing, that Lutris won't work anymore, is just the thing that made me install latest Wine and run into this weird bug.
Like I said, I used older Wine versions with Lutris (up to 6.x versions), and all of those versions doesn't have this bug, this weird "@u" name instead the normal user-name, when creating/changing a prefix. But, when Lutris broken I had to install Wine. (I doesn't even had installed any Wine into my system, because Lutris could use any verions without installing it on the system, it uses it's own folder to store and run from, any version that are set in Lutris.)
The problem is; that garbage wierd user-name, the "@u", now the new Wine version creating in the wineprefix user folder. Instead of the normal user name, like older versions do it correctly.
From my previous post:
"The problem is when I createa a new (or try to change an existing wineprefix to use this system version), the user name is not my real username that I logged in with. Now wine creates a strange garbage user name: "u@". Previously it was correct and alway created the proper user folder, with the user who logged in and run wine. "
https://bugs.winehq.org/show_bug.cgi?id=52732
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Ever confirmed|0 |1 Status|UNCONFIRMED |NEEDINFO
--- Comment #3 from Austin English austinenglish@gmail.com --- A) You didn't provide the requested info (env | sort).
B) It's still very likely that this is an issue on your system, not wine. No one else has reported a similar bug (not that it's impossible, but again, unlikely).
I'd suggest trying an older version of wine and see if the issue occurs there. If not, you could run a regression test (https://wiki.winehq.org/Regression_Testing) to see what in wine caused the problem.
If, on the other hand, you install older wine and the issue still occurs, it will show you that the problem lies elsewhere.
https://bugs.winehq.org/show_bug.cgi?id=52732
--- Comment #4 from Rafał Mużyło galtgendo@o2.pl --- To put in in plain text: I've read exactly what you've wrote and based on that decided that with a very high probability the problem you think you have is not the problem you actually have.
https://bugs.winehq.org/show_bug.cgi?id=52732
--- Comment #5 from Rencer rencer@euromail.hu --- Bro, what?!?
(In reply to Rencer from comment #0)
...so I had to install wine from system repo. The latest version in 7.4
...
Long time ago, before I started using Lutris (I'm not sure which wine version that was, around 4.x) I used command line to run wine, create prefixes, or run any Windows programs and never was this bug. Also most of the progrmas I installed with older versions and later never changed it, I think the last version that I used with Lutris is 6.something and it also don't had this user-name bug.
There is the answare, in my original report... I already answared to the question you just asked:
" installed with older versions and later never changed it, I think the last version that I used with Lutris is 6.something and it also don't had this user-name bug. "
SO... the old wine prefixes that I have, which are created with older 6.x Wine versions, don't have this problem. Running anything inside those wine-prefixes, THOSE older Wine versions, don't have this bug, just the newer ones that I forced to use; because of that other thing, which didn't have anything to do with this wine bug!
EVEN, if I still can use Lutris, which is really not even a software, just a frame to manage the Wine versions that are grabbed from the https://dlDOTwinehqDOTorg/wine/source/ site. From the home of the fabolous ORIGINAL TRUE WINE VERSIONS... And just running them via scripting (with Python, which is just another scripting thingie.) Exaclty like if I run any Wine version within any wineprefix, that I created with any Wine version, in terminal, command-line, CLI. So, if you know how this things work, than you already clearly must have to know, that those have nothing to do with this bug. Because I wont even using them anymore. It's impossible, because they dont work anymore. They just the reasons, how I was find out this wierd, 7.x versions releated bug.
And because of this weird behavior, some Windows-programs I need to use, won't work properly.
Cleraly, you don't grab the meaning of my sentences, im very sad about this unfortunate conversation with you, Rafał Mużyło, from now on, I will just wait for other reply, maybe someone else can look into this ting, and can find out what it is. Clearly, Lutris don't work anymore for me, so I it is impossible that I running those scripting thingies, A.K.A.; Lutris, Python. Henece, I MUST run all and every prefix from now-on, -new or older- in a terminal, command-line, CLI...
Than, here is another few sentence from one of my reply;
(In reply to Rencer from comment #2)
...
The problem is; that garbage wierd user-name, the "@u", now the new Wine version creating in the wineprefix user folder. Instead of the normal user name, like older versions do it correctly.
...
There is the answare, again(!) to the question you just asked; "...that garbage wierd user-name, the "@u", now the new Wine version creating in the wineprefix user folder." and "...like older versions do it correctly."
SO... ONLY the older Wine versions working correctly, won't have this weird bug. ONLY the newer version creating this garbage folder-name user-name.
https://bugs.winehq.org/show_bug.cgi?id=52732
--- Comment #6 from Rencer rencer@euromail.hu --- (In reply to Rafał Mużyło from comment #4)
To put in in plain text: I've read exactly what you've wrote and based on that decided that with a very high probability the problem you think you have is not the problem you actually have.
It's a REAL problem, it happening in every new Wine prefix with the new Wine version (runnig in terminal, command line, CLI), and in every existing Wine porefix that I tried to update to new Wine version. When I runnig in terminal, command line, CLI, any older Wine versions and creating a new OR just using an already existing Wine prefix, don't have this bug.
It doesn't matter what YOU decided, this thing is still happening, and this starge thing ONLY happennig with Wine. Only when I need to run a Windows-software. Everything else is working as needed in my system to run a Windows-software, only problematic is the new Wine-vesrions itself. Nothinng else.
Because of that you can't reproduce, or this, my report is the first one thatmention this bug that doesn't mean it is not real.
I already learned that if it is Wine, it can take very LONG time to even talk about it. (I had a bug a very long time that affected Wine, and that is fixed after more than 3 years, after countless of comments, contless of merging releated bug reports...) Maybe later something come up that can related to this and can be helpful to eliminate this thing.
So, this bug report is still open and real.
https://bugs.winehq.org/show_bug.cgi?id=52732
--- Comment #7 from Rafał Mużyło galtgendo@o2.pl --- (In reply to Rencer from comment #5 and comment #6)
...a lot of ranty bullshit...
Please stop taking steroids, they're really bad for you and should only be used under qualified medical oversight.
Given how wine determines username, even your rants contradict you. If the recreated prefix is recreated consistently then - given how wine determines your username (by my reading of relevant part of ntdll) - you have a mess in your environment.
So, I'm not arguing you don't have a problem, but that's it's a very local one, looking more and more like a PEBCAK.
https://bugs.winehq.org/show_bug.cgi?id=52732
--- Comment #8 from Rafał Mużyło galtgendo@o2.pl --- Anyway, besides the previously requested data, also attach userdef.reg from a fresh prefix exhibiting this problem.
https://bugs.winehq.org/show_bug.cgi?id=52732
Zeb Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12@gmail.com
--- Comment #9 from Zeb Figura z.figura12@gmail.com --- (In reply to Rafał Mużyło from comment #7)
(In reply to Rencer from comment #5 and comment #6)
...a lot of ranty bullshit...
Please stop taking steroids, they're really bad for you and should only be used under qualified medical oversight.
Given how wine determines username, even your rants contradict you. If the recreated prefix is recreated consistently then - given how wine determines your username (by my reading of relevant part of ntdll) - you have a mess in your environment.
So, I'm not arguing you don't have a problem, but that's it's a very local one, looking more and more like a PEBCAK.
Rafał, please be civil; you are not helping anything. Responses like "you have a setup problem", while possibly accurate, are not useful if the reporter has no way to determine what that setup problem is. Nor is it certain that there's not a Wine bug.
To the original reporter:
Wine retrieves the user name from the $USER variable. If empty, it's retrieved from getpwuid()->pw_name, and if that's also empty it defaults to "wine". So two things that may be helpful here:
(1) What is the value of $USER, printed from a host shell?
(2) What is the output of `wine cmd /c "echo %WINEUSERNAME"`?
https://bugs.winehq.org/show_bug.cgi?id=52732
--- Comment #10 from Rencer rencer@euromail.hu --- Oh, sorry, I forgot to include what Rafalla asked:
Output of the "sort | env" command:
COLORTERM=truecolor DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus DESKTOP_SESSION=xfce DISPLAY=:0.0 EDITOR=/usr/bin/nano GDM_LANG=en_US.utf8 GDMSESSION=xfce GTK_MODULES=canberra-gtk-module:canberra-gtk-module HISTFILESIZE= HISTSIZE= HOME=/home/ubermensch LANG=en_US.utf8 LC_ADDRESS=en_US.UTF-8 LC_IDENTIFICATION=en_US.UTF-8 LC_MEASUREMENT=en_US.UTF-8 LC_MONETARY=en_US.UTF-8 LC_NAME=en_US.UTF-8 LC_NUMERIC=en_US.UTF-8 LC_PAPER=en_US.UTF-8 LC_TELEPHONE=en_US.UTF-8 LC_TIME=en_US.UTF-8 LOGNAME=ubermensch MAIL=/var/spool/mail/ubermensch MOTD_SHOWN=pam PANEL_GDK_CORE_DEVICE_EVENTS=0 PATH=/home/ubermensch/.local/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/home/ubermensch/Utils/OpenJ9/jdk8u311/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl PWD=/home/ubermensch QT_QPA_PLATFORMTHEME=qt5ct SESSION_MANAGER=local/ubermenschPC:@/tmp/.ICE-unix/665,unix/ubermenschPC:/tmp/.ICE-unix/665 SHELL=/bin/bash SHLVL=0 SSH_AGENT_PID=711 SSH_AUTH_SOCK=/tmp/ssh-XXXXXXnzBbkY/agent.710 TERM=xterm-256color USER=ubermensch _=/usr/bin/env VTE_VERSION=6602 WINDOWID=37748739 XAUTHORITY=/home/ubermensch/.Xauthority XDG_CONFIG_DIRS=/etc/xdg XDG_CURRENT_DESKTOP=XFCE XDG_DATA_DIRS=/usr/local/share:/usr/share XDG_GREETER_DATA_DIR=/var/lib/lightdm-data/ubermensch XDG_MENU_PREFIX=xfce- XDG_RUNTIME_DIR=/run/user/1000 XDG_SEAT_PATH=/org/freedesktop/DisplayManager/Seat0 XDG_SEAT=seat0 XDG_SESSION_CLASS=user XDG_SESSION_DESKTOP=xfce XDG_SESSION_ID=1 XDG_SESSION_PATH=/org/freedesktop/DisplayManager/Session0 XDG_SESSION_TYPE=x11 XDG_VTNR=7
https://bugs.winehq.org/show_bug.cgi?id=52732
--- Comment #11 from Rafał Mużyło galtgendo@o2.pl --- (In reply to Poncer from comment #10 - equivalent exchange, buster)
USER var seems correct, you might still check userdef.reg. Though that should have been an attachment, for one cause bugzilla's wrapping makes some of the lines ambiguous.
Check also 'echo %USERPROFILE%' within 'wine cmd'. Yet, the later values within PATH (those perl derived) look a bit fishy.
(@Zeb: the former comment actually was me being civil; as for whether it is a wine bug or not, it's not completely out of the question, yet given no duplicates for over one release and that bit about python (mess in the environment could fuck python badly in hard to predict ways) seems quite unlikely)
https://bugs.winehq.org/show_bug.cgi?id=52732
--- Comment #12 from Rafał Mużyło galtgendo@o2.pl --- ...actually doing it piecewise might be tedious, so simply run 'set' in 'wine cmd' - that will give all environment vars; Some will be duplicated from shell (at least they *should* be), other will be Windows specific.
This should show if the environment isn't getting corrupted upon going into wine.
-
WineHQ Bugzilla