Created attachment 143283 [details] Part of the Dolphin window showing the error message (in Norwegian) that appears SUMMARY I got a new laptop with openSUSE pre-installed (yes!) - but the user name was "user". I asked Google how I could rename the user and found the usermod commands to rename the user and change the user's home directory. Everything worked fine until I pressed the "Home" button in Dolphin's Places panel. I then got the error message in the attached screenshot, which referred to the previous home directory location /home/user. I checked the System Settings to see if the locations were incorrect, but they were not - and the "Home" folder icon on the desktop worked as expected. However, in the file ~/.local/share/user-places.xbel the "Home" bookmark is stored as href="file:///home/user" - and all the default places for my home directory refer to /home/user I have never renamed a user before during the 20 years I have used Linux, so I am setting the severity to minor. It would be nice to have it solved, but it's something most people will never encounter. I can think of at least three distinctly different solutions: 1) Execute a script on initialization (KWin startup?) to synchronize the 'bookmarks' with locations from System Settings 2) Don't store the full path, use ~/ to refer to the home directory and add (library?) code to get the full path when 'places' are requested - that approach would be beneficial also for places added by users 3) Don't store the location for these bookmarks at all, get it from system settings and store only the "Hide" option's value STEPS TO REPRODUCE 1. Rename the login user and update the user's home directory name/location 2. Start a KDE (Plasma Desktop) session 3. Open Dolphin 4. Click on 'Home' in the Places panel I have not tested, but I expect the same result can be achieved by changing the user's home directory location, e.g. changing the home directory of user "chameleon" to "/home/tux" OBSERVED RESULT Dolphin does not display the home directory and issues the error message "The file or directory [old_home_directory] does not exist". EXPECTED RESULT Dolphin displays the files and folders in the home directory SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: openSUSE Leap 15.3 KDE Plasma Version: 5.18.6 KDE Frameworks Version: 5.76.0 Qt Version: 5.12.7 ADDITIONAL INFORMATION None
*** This bug has been marked as a duplicate of bug 428112 ***
I installed openSUSE Tumbleweed to check if this bug really was fixed in 5.25. Either it was not, or there has been a regression. Steps to reproduce: 1. Logged in as any user, create a new user "user2" with home directory /home/user2 2. Log out 3. Log in as user2 4. Open Dolphin 5. Log out 6. Log in as root 7. Execute the following commands (e.g. in Konsole): 7a) usermod -l user1 user2 7b) usermod -d /home/user1 user1 7c) mv /home/user2 /home/user1 8. Log out 9. Log in as user1 You can now observe the following: * If you open Dolphin you will see an error message about non-existing directory * If you open System Settings → Applications → Locations the correct file paths are displayed * If you open ~/local/share/user-places.xbel the old paths are stored in the bookmarks, e.g. <bookmark href="file:///home/user2"> <title>Home</title>
usermod call is not something easy for the system to recognize. We would need to check uid at plasma or application startup and deduce that $HOME has changed and replace path in `~/.local/share/user-places.xbel`. Another way to fix this would be to make KFilePlacesModel expand $HOME (i.e $HOME would be used in paths), xdg `user-dirs.dirs` file does this. The manpage of usermod states also: ``` You must change the owner of any crontab files or at jobs manually. ``` So there is a precedent of letting the user handle the consequences of a usermod. It is not a common operation for users. It could be handled more easily when editing the username using `kcmshell5 kcm_users` (although I am not sure it moves paths) but that's not what the bug is about. There is a very simple workaround: On the other hand there is a simple GUI tool available in `kcmshell5 kcm_desktoppaths` to correct the paths. Clicking reset to defaults should fix the entries.
Hi, I also experienced the same bug in the newest update. The Commands I have used to change my username: usermod -l beer -m -d /home/beer lube groupmod -n beer lube
There is a very simple workaround: There is a simple GUI tool available in `kcmshell5 kcm_desktoppaths` to correct the paths. Clicking reset to defaults should fix the entries. Beside this use case is not worth spending resources to support it.
Hmm, not sure I agree. When the system is in this state, a ton of things are going to start breaking in weird and random-looking ways. Yes, there's a workaround, but users don't know the workaround, and nothing in the UI tells them. Can we reconsider?
(In reply to Nate Graham from comment #6) > Hmm, not sure I agree. When the system is in this state, a ton of things are > going to start breaking in weird and random-looking ways. Yes and user-places.xbel is only one of them. Fixing this one won't fix the other issues. If a user uses usermod command what should they expect ? > Yes, there's a > workaround, but users don't know the workaround, and nothing in the UI tells > them. Now there this bug that documents it. > > Can we reconsider? Anyone voluntary can take care of this.
If it was just a matter of people manually running `usermod` on the command line, I would agree that we can consider it an expert use case that people should be able to take care of themselves. But we allow people to change their usernames in the users KCM, which means it's exposed to everyone.
*** Bug 478191 has been marked as a duplicate of this bug. ***
My issue was duped to this, but I reported something specific that hasn't been covered here, so if this issue is going to deal with both problems, I want to document it clearly in a comment. Méven Car wrote: > usermod call is not something easy for the system to recognize. > We would need to check uid at plasma or application startup and deduce that > $HOME has changed and replace path in `~/.local/share/user-places.xbel`. > ... > There is a very simple workaround: > On the other hand there is a simple GUI tool available in > `kcmshell5 kcm_desktoppaths` to correct the paths. So up until this point this bug deals with what happens if the user manually changes the paths. A workaround for the broken places is, after you change the paths, to update those changes using the `kcm_desktoppaths` KCM. My bug adds is the specific report that this *does not work*, at least under the Plasma 6 beta. In Bug 478191 I changed a path (the "Desktop") path to a new location, but changing the path in the `kcm_desktoppaths` KCM *does not* update the location used in Dolphin or elsewhere that "places" appear. In Dolphin, I see the error "The file or folder /home/<user>/Desktop" does not exist after changing the path shown in the KCM and restarting Dolphin. To my mind, this makes it a separate issue. Either way, a fix for this issue that keeps all the paths up to date automatically would likely fix my issue as well.
I've quickly scanned the KCM code for `desktoppaths`: https://invent.kde.org/plasma/plasma-desktop/-/tree/master/kcms/desktoppaths It appears that the KCM only updates the user-dirs.dirs used by XDG tools, it does not update user-places.xbel used by Dolphin and others. I think it *should* do so, regardless of whether this issue can be fixed for the generic username change use case.
(In reply to Adam Fontenot from comment #12) > I've quickly scanned the KCM code for `desktoppaths`: > https://invent.kde.org/plasma/plasma-desktop/-/tree/master/kcms/desktoppaths > > It appears that the KCM only updates the user-dirs.dirs used by XDG tools, > it does not update user-places.xbel used by Dolphin and others. > > I think it *should* do so, regardless of whether this issue can be fixed for > the generic username change use case. Agreed, as so many things *should* be. You can edit any places in the places panel through the magic of right clicking on them (aka context menu). Or even edit the file since you discovered its location.