21

There's an application on my system which keeps creating an empty ~/Desktop directory again and again. I can't stand capital letters in my home, nor I can stand this “desktop” thingy. So, as picky as I am, I remove the directory each time I see it. I'd really like to know which application is responsible for that (probably some application I won't use so often¹).

Any good ideas to track down the culprit?

—
1. Obviously I'd like to get rid of it, or maybe patch it if I can't live without it.

| improve this question | |
11

This directory might be created by any application that follows the Freedesktop userdirs standard. That potentially includes all Gnome or KDE applications.

If you want to know which application creates the file, you can use the LoggedFS filesystem or the Linux audit subsystem. See Is it possible to find out what program or script created a given file? for more information.

| improve this answer | |
  • So my question is an exact duplicate… Thanks! – Stéphane Gimenez Sep 23 '11 at 23:14
  • And your answer(s) there seems to be the only one(s) that actually answer the question. – Stéphane Gimenez Sep 23 '11 at 23:22
  • @StéphaneGimenez Technically the question is a duplicate, but for that particular case the right answer for most people is that it's created by some Freedesktop-compliant application and it's useless to fight it (I tried, and then I created a ~/.config/user-dirs.dirs). For example a comment in my user-dirs.dirs reminds me that on Ubuntu, I found that the directories are created by xdg-user-dirs-update called from /etc/Xsession.d/* at login time. – Gilles 'SO- stop being evil' Sep 24 '11 at 11:05
8

This looks like a directory from one of the free desktop standards. Any application compliant with it could be creating it.

Those "standard" directories can be specified in $HOME/.config/user-dirs.dirs. You can change the name there not to start with a capital letter and to be hidden somewhere, but getting totally rid of will be difficult.

There is one program (xdg-user-dirs-update) whose aim is to create those directories, see xdg-users-dirs. If should be able to deactivate it by having a $HOME/.config/user-dirs.conf containing

enabled=False
| improve this answer | |
  • Workarounds are welcome, but I'd like to know which application is creating this directory (I'd like to to catch it at the moment the directory is created again). – Stéphane Gimenez Sep 23 '11 at 20:32
  • Thanks, I'll try that. But I can only hope that the application is not creating the directory by itself. – Stéphane Gimenez Sep 23 '11 at 20:32
  • Where did you find this enabled info? Reading xdg-users-dirs, this seems to have no influence on the script at all. – Stéphane Gimenez Sep 23 '11 at 20:46
  • Here and then reading /etc/xdg/user-dirs.conf – AProgrammer Sep 24 '11 at 5:12
  • Ok thanks, the program that reads the conf file is xdg-users-dirs-update. – Stéphane Gimenez Sep 24 '11 at 9:34
0

If you're a complete graphical environment on your box (X and some desktop environment like Gnome or KDE), it'll undoubtedly a process of your desktop environment. It'll probably create the Desktop directory each time you log in. The process responsible for creating the directory is completely dependent on which desktop environment you're running.

| improve this answer | |
  • The question was generic because it's an isolated process. I'm not using any "graphical environment", just an X11 server with a barely minimal window manager. – Stéphane Gimenez Sep 23 '11 at 20:09
0

On Debian and Ubuntu you could see that there is an entry user-dirs-update-gtk.desktop in /etc/xdg/autostart/.

Removing that entry prevents from creating user directories again.

Been a thing coming from freedesktop standard, it is probable that this works in other distros too.

| improve this answer | |
  • Nothing there (but the directory exists). I was looking for a generic method to find which process attempt to create a specific directory. – Stéphane Gimenez Sep 23 '11 at 19:59
  • @StéphaneGimenez: it was not clear to me from the beginning that the method to track down the problem was more important to you than the problem itself. – enzotib Sep 24 '11 at 8:21
0

If the application is still running, you may be able to find an open file in that directory using lsof. Since the directory is only part of the filename, i don't think you'd be able to use it as lsof's parameter, so you'd need to grep for a part of it. 

lsof | grep $HOME/Desktop
| improve this answer | |
  • This is unlikely to work, because the application is unlikely to have a file open under ~/Desktop at the time you run lsof, and it may well have created the directory and done nothing else inside it anyway. – Gilles 'SO- stop being evil' Sep 23 '11 at 22:29
  • Hence the "you may". The other answers on preventing this, and it being the desktop libraries that are probably responsible make sense. However, were it some file being created like this on a device, I'd start with this method, and failing that, start things with an ld preload and asserting when they tried to create that dir - obviously far too extreme for this question, but fun. – Danny Staple Sep 24 '11 at 9:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.