xdg user-dirs not being read/stored correctly for desktop icon in left panel

Bug #1768961 reported by Scott Cowles Jacobs on 2018-05-03
This bug affects 1 person
Affects Status Importance Assigned to Milestone
lubuntu-default-settings (Ubuntu)

Bug Description

I have my personal data in a separate partition, and when I do a new install of a distro
(Originally Ubuntu, then Lubuntu for a long time, now Lubuntu Next) always change xdg's user-dirs.dirs to point at directories in my partition:

When I invoked PCManFM to test something (I use Nemo regularly), and clicked on what I believe is the icon for "Desktop" in the left panel, I get the error window with the text:
Error when getting information for file “/home/scott/"/data/scott/Desktop" ”: No such file or directory

(ah, yes - I see that there IS text for the left panel icons, it is merely that as the default display comes up, there is no room to show anything next to the icons except "...")

The bookmarks in the left panel, and in the menu DO seem to work correctly, and point to my re-defined user-dirs.

It appears that only the desktop icon in the left panel has a problem...

scott@scott-ASUS-M2N68-AM-PLUS:~$ uname -a
Linux scott-ASUS-M2N68-AM-PLUS 4.15.0-20-generic #21-Ubuntu SMP Tue Apr 24 06:16:15 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
scott@scott-ASUS-M2N68-AM-PLUS:~$ lsb_release -dsc
Ubuntu 18.04 LTS
scott@scott-ASUS-M2N68-AM-PLUS:~$ echo $DESKTOP_SESSION
scott@scott-ASUS-M2N68-AM-PLUS:~$ apt-cache policy pcmanfm-qt
  Installed: 0.12.0-5
  Candidate: 0.12.0-5
  Version table:
 *** 0.12.0-5 500
        500 http://us.archive.ubuntu.com/ubuntu bionic/universe amd64 Packages
        100 /var/lib/dpkg/status

ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: pcmanfm-qt 0.12.0-5
ProcVersionSignature: Ubuntu 4.15.0-20.21-generic 4.15.17
Uname: Linux 4.15.0-20-generic x86_64
ApportVersion: 2.20.9-0ubuntu7
Architecture: amd64
CurrentDesktop: LXQt
Date: Thu May 3 15:24:51 2018
InstallationDate: Installed on 2018-04-29 (4 days ago)
InstallationMedia: Lubuntu-Next 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180421)
 PATH=(custom, no user)
SourcePackage: pcmanfm-qt
UpgradeStatus: No upgrade log present (probably fresh install)

Walter Lapchynski (wxl) wrote :

Is this $HOME/.config/user-dirs.dirs that you're editing or /etc/xdg/user-dirs.dirs?

Walter Lapchynski (wxl) wrote :

For that matter, what is $HOME for you?

This is $HOME/.config/user-dirs.dirs.
(I'm a little fuzzy on the details, but I believe that xdg looks for user-dirs.dirs in $HOME/.config, and if it does not find it, creates it from the default file in /etc/xdg
No, I guess not - I just had a look in /etc/xdg and found only user-dirs.defaults (which contains only "relative pathnames from the home directory").)

>what is $HOME for you?
I have not re-defined $HOME, as (some years ago) when I was researching the best way(s) to set up one's hard drive, I believe I found a consensus that it was best to let a distro's apps put their config. and other stuff in the standard place ($HOME) in the root partition, but have xdg user-dirs redirect ones personal data to a separate /data partition, so that all one's distros (current and past - I reserved space for 5 distros + swap and /data) can access the same personal data, but each install has a completely clean install of app config files (normally in $HOME/.config)

Therefore, home is the standard /home/scott
It contains what appear to be the personal directories (Desktop/Documents...), which were probably created at install, but they are all empty.

I just noticed that ScreenGrab, in its Browse for default save directory,
does exactly the same thing:
Desktop under "Places" comes up as directory buttons (each of the following is its own button):
  / home scott " data scott Desktop"

Note that there is a directory button containing only the quote character, and
that the last directory has the name Desktop with attached quote mark on the end.

I have to assume that both programs PCManFM and ScreenGrab utilize the same routine for scanning for user directories, and that that routine is what is screwing up "Desktop".

What is that routine, and where is it located (what pkg), so that I can point this bug report in the right direction?

Walter Lapchynski (wxl) wrote :

I changed $HOME/.config/user-dirs.dirs so that XDG_DESKTOP_DIR="$HOME/Desktop/foobar" and everything seems to behave fine, so I can't replicate your experience, which makes it hard to fix. Could you start with a fresh system (maybe a virtual machine) and come up with some clear steps?

Barring that, you might bark up the tree of libqt5xdg3 but there's nothing about it, from what I can tell, that deals with the Desktop directory different than any others.

Changed in pcmanfm-qt (Ubuntu):
status: New → Incomplete

@Walter Lapchynski (wxl)

The incorrect Desktop reference in the left panel seems to be a combination of the original and the other-partition directory.

It seems to want to use $HOME as part of the reference, even though $HOME was not part of the actual directory path in userdirs.dirs.

Have you tried to use a reference that does NOT include $HOME ?

Walter Lapchynski (wxl) wrote :

Nope, but it should be irrelevant. If what you're saying is consistent, it should end up looking in $HOME/Desktop/$HOME/Desktop/foobar, no?

My point, I guess, was that even though my xdg user-dirs.dirs directory for Desktop was:
(an absolute path - no reference to $HOME)
pcmanfm-qt and a number of other programs (just was using qpdfview today and had the same problem) apparently insisted upon adding /home/scott to the beginning of my directory line, along with some spurious quote marks...

Do programs that open/save files from one of the xdg user dirs go to the ~/.config/user-dirs.dirs EACH TIME THEY OPEN, or is there some OTHER file somewhere that gets created at login FROM the xdg user-dirs file that these files then access, and not the xdg file directly?
In which case, this OTHER file may be being created incorrectly, and then all these other programs that read it may then be correctly reading the incorrect file.
This makes more sense to me, than that somehow all these programs are reading/interpreting the xdg file incorrectly in EXACTLY THE SAME WAY.
(What are the odds of THAT?)

I suspect that there is some ReadXDGUserDirs () function in one library somewhere, that all these different programs are calling.
I suppose it is a Qt-related library.
(I don't believe Nemo is Qt-based, and it did not (as I recall) have the same bad reference to Desktop.)

Hmmm... Let's see just which programs [don't] have the problem:

GIMP, catfish, eog, OCRFeeder, Hugin, gdebi, mkusb, Archive Manager all seem to use my /data/scott directory for Desktop.

Ark, QtPass, E-Book viewer, LXImage, LRF Viewer, Nomacs, Skanlite, QTransmission, Quassel, Calibre, SimpleScreenRecorder, PCManFM-qt all seem to have the mangled Desktop reference...

[Other programs either don't appear to load/save (and hence no file-selector), or for some reason have virtually no buttons in the left panel (typically "computer" and "scott").]

This seems to confirm that all programs that are Qt-derived that use a file-selector use the same code for it, and thus have the same behavior...

Walter Lapchynski (wxl) wrote :

I just set Desktop to /blah and everything works fine in pcmanfm-qt and
calibre, for example. That said, I cannot reproduce your issue.
Something must have changed about your system that is causing these
issues, but I have no idea what they are.

I don't know - if you don't try it, you won't know.
The code may behave differently if it finds the string "$HOME",
than if it does not.

I have downloaded the source for libfm-qt-0.12.0 and libqt5core5a,
and have found what may be relevant code, but since I am not C++ literate
(I did C some decades ago, but object-oriented stuff twists my brain into pretzels).

If your brain is better equipped for it than mine, have a look at the files indicated in the attachment. I was making notes for myself to try to find
the problem.

Walter Lapchynski (wxl) wrote :

I *DID* try it. I set Desktop to /blah (note, there's no $HOME in there) and it did not fail.


I have now re-purposed one of my previous distro-partitions, and
did a minimal install of Lubuntu Next, as I did before.

Upon booting into the new install, Desktop is what you would expect:
/home/scott/Desktop. Fine.

Upon updating software (updating packages that changed since the April 21 .iso)
things are just the same.

Upon swapping out the default xdg user-dirs.dirs for mine (shown above),
and then logging out and logging in again, the problem manifests IMMEDIATELY.

Clicking on Desktop in PCManFM yields the error window with the text:
Error when getting information for file “/home/scott/"/data/scott/Desktop" ”: No such file or directory.

The buttons at the top (as described in comment #5 above) are:
  / home scott " data scott Desktop"

NOTE: When first installed, the desktop was blank.
Logging in from swapping user-dirs.dirs immediately showed my desktop files/dirs.

Therefore, PCManFM does SOMETHING differently when it looks for the desktop to handle the desktop, from when it looks for the desktop to assign the action for clicking on the Desktop button in PCManFM's left pane.
It is successful in the first instance, and unsuccessful in the second.

Either there are two separate snippets of code that look for the xdg user-dirs DESKTOP line (one correct, one incorrect), OR there is only one bit of code, but
PCManFM messes up AFTER it gets the correct string.

It looks to me as if there are actually two mistakes here:
1. it is using $HOME, when my line does not contain it.
2. it is mis-reading the line, and including the beginning and ending quote marks,
which should be cropped.

When I have time, I will try to find what .cpp file PCManFM uses to populate the left-pane buttons, and thus where the code is that looks for DESKTOP...
(but if you are familiar with the source, you will probably find it more quickly)

Walter Lapchynski (wxl) wrote :

Lubuntu Next is a product we never officially released and it's unsupported. I did have an old VM laying around (18.04) and could not reproduce this behavior. I could also not reproduce this behavior in an 18.10 daily (20180515), which WILL be a released version of Lubuntu with LXQt (which was what we were aiming towards with Lubuntu Next but that "product" was rather confused). Here's what I did:

 1. sudo mkdir -p /data/scott/{Downloads,Templates,Public,Documents,Music,Photos,Videos}
 2. sudo chown -R $USER /data/scott
 3. sed -i 's|\$HOME|\/data\/scott|g' ~/.config/user-dirs.dirs
 4. logout and back in again

Maybe the file you're swapping in contains some invalid characters or otherwise have bad syntax? Or maybe your user does not have permissions to access those folders (see step 2).

I will attach two screengrab'd files that show Nemo's and PCManFM's Properties->Permissions for my /data/scott/Desktop directory.

See if you see any issue...

To my inexperienced eye, nothing seems wrong - the owner IS scott, and the owner has read/write/execute permissions for the directory ("view and modify folder content")

The only difference that I can see between the permissions for /data/scott/Desktop and /home/scott/Desktop is that for /home/scott/Desktop, "Group" has write permission, and it does not for /data/scott/Desktop.

I'm not sure how relevant "Group" is here, as there is only me...

Walter Lapchynski (wxl) wrote :

To be clear, I didn't say you're crazy, but that I can't reproduce this. Maybe you should try following what I did in a clean system (try a virtual machine)?

Meanwhile, just for my clarification, please give me the results of:
ls -ld /data/scott/{Desktop,Downloads,Templates,Public,Documents,Music,Photos,Videos}

>Maybe you should try following what I did in a clean system
>(try a virtual machine)?
I did.
I did a complete fresh install in one of my partitions.
"Desktop" did its default "/home/scott/Desktop" initially.
Then I swapped out the default user-dirs.dirs with mine (see above),
logged out, logged in, and it was just as I reported it above
(see initial description,as well as #13).
I had not added any packages (but did update-software, to get the
updated packages that had changed since install).

I have now booted into my old Lubuntu Next 17.10 install, to see what
PCManFM-qt was doing there.

It reports the correct Desktop location: "/data/scott/Desktop"
No problem at all.

To summarize:

In BOTH Lubuntu Next 17.10 and 18.04 (the final dailies of each),
PCManFM-qt finds/uses "/data/scott/Desktop" correctly for handling the
actual desktop (displaying the icons on the desktop, etc.)


Lubuntu Next 18.04's PCManFM-qt does not find/use the correct directory
for the left panel Desktop button, whereas Lubuntu Next 17.10's version

For Lubuntu Next 17.10 final daily (possibly updated in its 6 month life):
pcmanfm-qt version: 0.11.3-4
libfm-qt3 version: 0.11.2-2build1
liblxqt0 version: 0.11.1-2
libqt5xdg2 version: 2.0.0-8


[I even booted into Lubuntu 17.04, and PCManFM (non-Qt) correctly handled my
desktop directory for the left panel Desktop button.
pcmanfm version: 1.2.5-2ubuntu0.1]

Walter Lapchynski (wxl) wrote :

Like I said, Lubuntu Next is unsupported. Never has been.

What I'm asking for you to do is to test the current daily, as it's the only supported version of Lubuntu with LXQt.

Having now installed the 05/25 daily of Cosmic (18.10) in my test partition,
I can confirm that the bug is still present.

$ uname -a
lsb_release -dsc
Linux scott-Asus-M2N68-AM-Plus 4.15.0-22-generic #24-Ubuntu SMP Wed May 16 12:15:17 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
$ Ubuntu Cosmic Cuttlefish (development branch)
$ Lubuntu

$ apt-cache policy pcmanfm-qt
  Installed: 0.12.0-6
  Candidate: 0.12.0-6
  Version table:
 *** 0.12.0-6 500
        500 http://archive.ubuntu.com/ubuntu cosmic/universe amd64 Packages
        100 /var/lib/dpkg/status

(see screenshot)

Having said that, I read (from bug #1772214 ) that:
Alf Gaida (agaida) wrote on 2018-05-20: #4
Anyways - one can consider all libfm-qt and pcmanfm-qt bugs for versions < 0.13 not relevant for cosmic - libfm-qt and pcmanfm-qt got heavy modifications for 0.13 so most of the 0.12.0 bugs are not relevant for cosmic (massive parts of libfm-qt are rewritten in c++ and don't use the old libfm stuff anymore). The interesting thing will be to catch bugs in the new version and iron them out until 18.10
So, naturally, I will want to test this once libfm-qt and pcmanfm-qt change to 0.13.x ...
1. Do we have an idea when this might happen?
2. Will it magically appear in Software Updater when it happens
(I assume developers don't need to always download a new daily, "burn" it
to media, and install it, whenever there is a change in an original package...)?

Here is the promised screenshot (which looks much like the last one, as nothing has changed).

Just as with LN 18.04, L 18.10's PCManFM-qt reads my user-dirs.dirs file correctly when
it handles the desktop, but not when the user clicks on the App's Desktop button in the left pane.

I have kept tabs on the .manifest files of the daily .iso , and I noted recently
that both PCManFM-qt and libfm-qt5 have now gone to 0.13.x versions.

Having now installed the 07/12 daily of Cosmic (18.10) in my test partition,
I can confirm that the bug is still present.

[Same procedure: install Lubuntu, PCManFM-qt says Desktop = "/home/scott/Desktop"
change to my custom user-dirs.dirs; log out, log in...
The desktop is now populated with my desktop icons.
So far so good...
Invoke PCManFm-qt. Clicking on PCManFM-qt's "Desktop" button yields the same mangled entry, with an error message, as first described.]

PCManFM-qt still reads the user-dirs.dirs file correctly in running the desktop (my many file/directory icons appear), but PCManFM-qt's Desktop left-pane button still results
in the mangled Desktop location.

Since (as I noted in #9) many other (apparently all qt-related) programs mangle the desktop
location as well, I assume it is not the package PCManFM-qt where the reading of user-dirs.dirs is being done for file open/save, but some other package - I assume libfm-qt_ .

Something changed between the pcmanfm-qt version: 0.11.3-4 (that I am using in LN 17.10), and the one that I was originally testing for LN 18.04 (0.12.0-5)
(or something changed in libfm-qt3, going from version 0.11.2-2build1 for LN 17.10, to version 0.12.0-14build2 for LN 18.04),
because it WORKED for the versions included in LN 17.10, and DID NOT WORK for the versions in LN 18.04 (and STILL does not work with the versions in L 18.10.)

libfm-qt3 has now become libfm-qt5, with its new 0.13.x version...


scott@scott-ASUS-M2N68-AM-PLUS:~$ apt-cache policy pcmanfm-qt
  Installed: 0.13.0-2
  Candidate: 0.13.0-2
  Version table:
 *** 0.13.0-2 500
        500 http://archive.ubuntu.com/ubuntu cosmic/universe amd64 Packages
        100 /var/lib/dpkg/status

scott@scott-ASUS-M2N68-AM-PLUS:~$ apt-cache policy libfm-qt5
  Installed: 0.13.1-5
  Candidate: 0.13.1-5
  Version table:
 *** 0.13.1-5 500
        500 http://archive.ubuntu.com/ubuntu cosmic/universe amd64 Packages
        100 /var/lib/dpkg/status

Simon Quigley (tsimonq2) wrote :
Changed in pcmanfm-qt (Ubuntu):
status: Incomplete → Confirmed
Simon Quigley (tsimonq2) on 2018-07-20
affects: pcmanfm-qt (Ubuntu) → lubuntu-default-settings (Ubuntu)
Akred (akred) wrote :

Hello everyone,

I think I have the same issue with Ubuntu 18.
I have the same behavior with VLC software (I don't now if it is related to QT)

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.