Desktop folder gets created sometimes and is recognized by pantheon-files

Bug #1088260 reported by Sergey "Shnatsel" Davidoff on 2012-12-09
This bug affects 47 people
Affects Status Importance Assigned to Milestone
elementary OS
Sergey "Shnatsel" Davidoff
Fix Released
Linda Lesser
Linda Lesser

Bug Description

Desktop folder is still recognized by pantheon-files and get created by applications sometimes. We should ditch it completely and redirect all requests to it to home folder. That's the default fallback for any nonexistent folders, but desktop folder has special handling. Our OS patches remove it, but it seems that's not sufficient.

Changed in elementaryos:
milestone: none → luna-beta2
status: New → Triaged

This is weird because "/usr/bin/xdg-user-dir desktop" prints the home folder but pantheon-files treats "~/Desktop" as a desktop folder

summary: - Desktop folder gets created sometimes and is recognized by xdg-user-dirs
+ Desktop folder gets created sometimes and is recognized by pantheon-
+ files
description: updated

I've committed the required changes to the OS patch of xdg-user-dirs, it was incompletely cleansed indeed.
I wonder if it will build in the recipe now.

Changed in elementaryos:
status: Triaged → Fix Committed
assignee: nobody → Sergey "Shnatsel" Davidoff (shnatsel)

And yet this doesn't seem to be sufficient.
Perhaps we should patch xdg-user-dirs-gtk too.

Oh my. The folder is present in live session and it's localized even with the latest patches...

XDG_DESKTOP_DIR is still present in ~/.config/user-dirs, so I guess my latest patch has actually regressed things.

Changed in elementaryos:
status: Fix Committed → In Progress

Ah, that was caused by the workaround for bug 1089615 suggested by Launchpad devs causing the patches to not be applied at all. Should be fixed now.

Changed in elementaryos:
status: In Progress → Fix Committed

That's still not sufficient. I've patched xdg-user-dirs-gtk too, let's see if that helps.

Changed in elementaryos:
status: Fix Committed → In Progress

STILL not sufficient. Man, in how many places did they manage to stick this special handling code?!

I'm afraid I'm out of ideas. Somebody else should have a look at this.

Changed in elementaryos:
status: In Progress → Triaged
assignee: Sergey "Shnatsel" Davidoff (shnatsel) → nobody
bwat47 (bwat47) wrote :

If this can't be done we should at least get the desktop icon added back to the elementary theme. When the desktop folder shows up it has a super ugly gnome icon. It wouldn't be a big deal IMO if it at least used a normal elementary folder icon...

According to a duplicate bug 1092658, the folder gets created on invoking the "open file" dialog from a web browser.

Clearflower (flowc111) wrote :

I caught it right in the action. Apperently, the "open file" dialog in firefox defaults to a directory in the file manager called /home/user-name/desktop. What happens is this directory doesn't exist inside files in the first place, so it makes a folder automatically - the "desktop" folder. Once you upload a file to a web dialog, it then stays in the directory if which the file was uploaded from, so obviously it won't happen in the same dialog again. I hope the image and the info helps.

Daniel Fore (danrabbit) on 2012-12-23
Changed in elementaryos:
milestone: luna-beta2 → luna-beta3

Setting "org.gnome.nautilus.preferences desktop-is-home-dir" in dconf to true seems to fix this. Pushed that to OS defaults.

Existing users will have to manually reset that key or create a new user account to get the fix. I'll reopen the bug if the problem persists.

Changed in elementaryos:
status: Triaged → Fix Committed

Nah, still happens here X(

Changed in elementaryos:
status: Fix Committed → Triaged
Cody Garver (codygarver) wrote :

Well, at least the latest fix got rid of an intrusive warning whenever you launch Nautilus.

Cody Garver (codygarver) wrote :

The only thing I've seen make a Desktop folder lately is Steam.

Cody Garver (codygarver) wrote :

Haven't seen one of these for a while, has anyone else?

Changed in elementaryos:
importance: Undecided → High
status: Triaged → Incomplete

Firefox creates it on opening "Open File" dialog.

Also it's not like we can patch every single piece of software this cycle. We need to make apps from recognize home folder as desktop folder instead of sticking to "~/Desktop".

Changed in elementaryos:
status: Incomplete → Triaged

After applying the following one-line patch to Glib I can no longer reproduce this bug.

Changed in elementaryos:
assignee: nobody → Sergey "Shnatsel" Davidoff (shnatsel)
status: Triaged → In Progress
description: updated
Cody Garver (codygarver) on 2013-05-13
Changed in elementaryos:
milestone: luna-beta3 → luna-rc1
Cody Garver (codygarver) on 2013-07-24
Changed in elementaryos:
status: In Progress → Fix Released
Cody Garver (codygarver) wrote :

Haven't experienced this on Trusty/Isis

Interestingly enough, it was somehow fixed in Luna... at least Pantheon Files no longer seems to consider Desktop folder a special one. No idea why.

Sascha Heuterer (theanachron) wrote :

Got this folder created again on Freya installation, using programs like NetBeans IDE which add shortcuts to the Desktop.

Abhinav (agauniyal) wrote :

I haven't installed Netbeans or any other IDE but it does gets created on Freya and on deleting returns back every time I login again.

Timo Reimerdes (timorei) wrote :

Seeing this happening on every login on current freya beta install.

Alex Viscreanu (alexviscreanu) wrote :

Bug stills on Freya Stable release.

Coeur Noir (coeur-noir) wrote :

Well, I've seen the same behavior on my fresh Freya (0.3) after installing Firefox.

Timo Reimerdes (timorei) wrote :

Workaround for firefox creating the Desktop folder over and over again:

~$ scratch-text-editor .config/user-dirs.dirs

make sure there is a line:

Not "$HOME" - for some reason some applications, firefox being one of them, seem to have a problem recognizing that var. In fact - just to make certain that all other directories are found as well, you can just replace all ocurances of $HOME/ with /home/<yourusername>/

Obiously fill in the name of your user for <yourusername>.

From now on, firefox is not creating the Desktop folder anymore. (I bet this is related to Telegram creating the darn fontconfig folder in Home... *sigh*)

Gabriel_P (gabp) wrote :

I'm getting this issue consistently with Zotero ( in Freya.

The standalone version creates a 'Desktop' folder every time the app opens.

Tried the patch above by Timo R but it didn't work.

Timo Reimerdes (timorei) wrote :

I just found my own answer and it works.

replaced all $HOME/ with /home/timo/

added the missing XDG_DESKTOP_DIR=/home/timo/

Firefor did not create the folder. Just make sure you have the line for the desktop present (it wasn't there at all after super-clean-install). Obviously replace "timo" with your own username.

Gabriel_P (gabp) wrote :

Just noticed that Google Chrome will store in this desktop folder the "apps" created with the new feature described here:

see 'Add a website as an app'.

Not sure how this will behave when no 'Desktop' folder is available.

Seth (sysfu) wrote :

Confirm that XDG_DESKTOP_DIR="/home/<yourusername>/" trick works with Thunderbird 38.8.0

Jung-Kyu Park (bagjunggyu) wrote :

This workaround doesn't work for non-English like Korean


Jung-Kyu Park (bagjunggyu) wrote :

My fault it worked for me in Korean, I fully misunderstood it.

Jung-Kyu Park (bagjunggyu) wrote :

Actually, This symptom happens not noly "Desktop" folder but also to "Downloads" when downloading files via Firefox.
In Korean , we have two folders for download files one for standard download folder by locale "다운로드", and "Downloads" created by Firefox.
Sometimes files are downloaded to the "Downloads" folder not to standard folder "다운로드"

That workaround worked for this case too,

Zisu Andrei (matzipan) on 2016-11-03
Changed in elementaryos:
status: Incomplete → Confirmed

Still present on Loki w/ Firefox. Can anyone else please confirm?

Timo Reimerdes (timorei) wrote :

Can confirm. But it's not just loki, any distribution not using a designated desktop folder is behaving this way.

But for me the .config/user-dirs.dirs workaround fixes it reliably:


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

Duplicates of this bug

Other bug subscribers