If for some reasons or another you noticed that your Xfce desktop became grey out of a clear blue sky, nonetheless the mouse left-right click responding in a weird manner, you better read this first.
First thing you tried was to logout-login your Xfce session. It didn't help. Then you tried to restart your system (just in case). Obviously this didn't work too because Linux doesn't need a restart like Windows for every single tiny problem. Well, some of you perhaps thought to reinstall the Xfce desktop (xfdesktop) or Xfce Window Manager (xfwm4) or (why not) the Xfce session (xfce4-session). Neither one of these worked. Then you asked your best friend, the Google and it come up with some brilliant (?!) ideas like: "try delete these folders entirely:"
~/.cache/sessions/
~/.config/xfce4/
STOP! Read this first!
I haven't deleted my files yet
In the rush of getting this annoying problem fixed you might try one of these crazy ideas but first let me tell what are you "advised" to do.
The ~/.cache/session contains any previously Xfce saved session settings like the active workspace, the current home/working directory, nothing that seems to have a crucial importance to me.
The ~/.config/xfce4 is another story. Just a simple `ls -la ~/.config/xfce4` would reveal what you are going to permanently remove:
drwxr-xr-x 6 eugen dev 4.0K Oct 20 00:13 . drwxr-xr-x 64 eugen dev 4.0K Oct 20 02:09 .. drwx------ 2 eugen dev 4.0K Oct 20 00:17 desktop -rw-r--r-- 1 eugen dev 33 Oct 20 00:13 helpers.rc drwxr-xr-x 9 eugen dev 4.0K Oct 20 08:27 panel drwxr-xr-x 3 eugen dev 4.0K Oct 19 23:56 xfconf drwx------ 2 eugen dev 4.0K Oct 19 23:56 xfwm4
Just to give you a hint I should tell you that the panel folder contains all your panels and launchers/shortcuts definitions. Before you remove it make sure that either you don't need them or if you do then make a backup first. The desktop folder contains the desktop shortcut definitions which may be just as important as the panel folder is.
Now regarding the xfconf folder just let's see what is inside:
drwx------ 2 eugen dev 4096 Oct 20 09:23 . drwxr-xr-x 3 eugen dev 4096 Oct 19 23:56 .. -rw-r--r-- 1 eugen dev 1386 Oct 20 00:17 displays.xml -rw-r--r-- 1 eugen dev 2859 Oct 20 08:10 thunar.xml -rw-r--r-- 1 eugen dev 329 Oct 20 00:04 xfce4-appfinder.xml -rw-r--r-- 1 eugen dev 3106 Oct 20 09:23 xfce4-desktop.xml -rw-r--r-- 1 eugen dev 10842 Oct 20 01:51 xfce4-keyboard-shortcuts.xml -rw-r--r-- 1 eugen dev 5576 Oct 20 08:57 xfce4-panel.xml -rw-r--r-- 1 eugen dev 1073 Oct 20 00:17 xfce4-session.xml -rw-r--r-- 1 eugen dev 336 Oct 20 00:18 xfce4-settings-editor.xml -rw-r--r-- 1 eugen dev 276 Oct 20 00:18 xfce4-settings-manager.xml -rw-r--r-- 1 eugen dev 5189 Oct 20 00:16 xfwm4.xml -rw-r--r-- 1 eugen dev 1702 Oct 20 00:42 xsettings.xml
If the panel folder earlier contained the launchers definitions the xfce4-panel.xml file on the other hand contains how these launchers are organized on your panel so basically this contains your panels definitions.
Never the less the xfce4-keyboard-shortcuts.xml file has a crucial importance to me because I am lazy and I don't like moving the mouse in all directions just to launch a shortcut. I (still) have a good memory and a lots of keyboard shortcuts (like 30 or so) so I don't want to accidentally remove them because, as I've said earlier, I'm lazy and don't like to redefine the whole desktop scheme just because of a stupid Xfce desktop grey thing. Look at the size of these files: the bigger one is `xfce4-keyboard-shortcuts.xml` so it might be important, right? What's next? Exactly, the `xfce4-panel.xml`. It is very important too, I cannot stress enough this (fixed) idea.
If we take a look at the xfwm4.xml file it seems to contain other settings related to Windows Manager.
I kept the juice for the end: the "delete these files" solution above will fix your Xfce desktop grey issue but keep in mind all I told you before. The folders you are going to delete (in order to fix the damn thing) contain capital information about how you organized your keyboard shortcuts, desktops, panels, windowing settings, whatever.
Oops, I deleted my files. Now what?
Ok, so you deleted your files. Now what? The only way to recover from this situation is to try to recover the deleted files. There are numerous methods of restoring deleted files in Linux (depending on their types, the filesystem you have, etc) but the one that works for this case is just to look up for all all inodes - even the deleted ones - (on the partition where those files were stored) that contain some keyword that we know it appears only within these "deleted files".
The Linux grep command is all we need. But what we know about these files is as important as the grep command itself:
- are they binary or just plain text files
- what are the keywords that only these files might contain
- which is the partition where these files were stored
(1) Basically these files are .ini files or .xml files so we can assume they are just plain TEXT files.
(2) Supposing you deleted these files probably you started with a default desktop scheme (default panels, default window settings, default anything). Perhaps these default files took place instead of your custom (but unfortunately deleted) files. Then just `cat` any of these files and find a piece of text that looks characteristic for these kind of files.
(3) The file system disk space Linux tool (df) is all you need. Just `df ~/.config` and you will get something like:
eugen@gentoo ~ $ df ~/.config/ Filesystem 1K-blocks Used Available Use% Mounted on /dev/root 20027260 11687776 7299100 62% /
So we see that this folder belongs to a partition mounted as `/`. Which might be that partition you may ask? Well, just `cat/etc/fstab` and check which partition has the mount-point `/`:
/dev/sdc1 /boot ext2 noauto,noatime 1 1 /dev/sdc2 / ext4 noatime,discard 0 2 /dev/sdd2 none swap sw 0 0 tmpfs /tmp tmpfs nodev,nosuid 0 0 tmpfs /var/tmp/portage tmpfs uid=portage,gid=portage,mode=775,size=2048M,noatime 0 0 /dev/vg/lvhome /home/eugen/lvhome ext4 defaults 0 2 http://webdav.local/share /mnt/dav davfs rw,user,noauto 0 0 /dev/sdd1 /sdd1 ext4 noatime,discard 0 0
In my case the `/` is mounted on partition `/dev/sdc2` so this is where I would look for my deleted files if I need to. But please note that your partition configuration has perhaps nothing in common with my local configuration so don't just copy-paste these thing on your terminal hoping that your problem get fixed that way, right?
Now that we have all the 1-2-3 answers let's see how we can use grep.
By grepping the inodes on the /dev/sdc2 partition we we get a bunch of binary blocks that might contain our keywords. So certainly they don't have plain text only and that is why we should inform grep to treat binary as text (the -a parameter). We can pass our keywords pattern by using the -F paramter. The grep will output by default all the contents to the stdout (your terminal) and, considering that the output may be anything from 5MB to 100MB, we want to capture this output to a file, right?
Finally the grep command should look like this:
grep -a -F 'some-unique-keyword-from-deleted-files' /dev/sdXY > /non-sdXY-dir/dump.txt
Note: it would be nice if your /tmp folder is mounted to a memory filesystem (like tmpfs) or to any partition that is not the same your deleted files were stored. The reason for that is that you don't want to give Linux the chance of overwriting these - now available - inodes such that the content of the previous deleted files get overwritten by your temporary dump file. Does it make sense? Just think about it!
It may take a while, depending on the keywords used, the partition size, the hard-disk read-write performances, etc. Anyway, after a while you get that `dump.txt` file. Now use whatever program you like and search for these keywords within the dump.txt file. They should appear in the neighbourhood of the file content that had/has the respective keyword within. If that is what you are looking for then use that piece of info and reconstruct manually the lost shortcut/whatever, otherwise just keep searching. Note that the grep command can be also used for this too (like `grep keyword dump.txt`)
Conclusion: backup the folders first and later do whatever works for you. It took ~1300 words to me just to explain you how to solve this!
Now, if you think that this article was interesting don't forget to rate it. It shows me that you care and thus I will continue write about these things.
Eugen Mihailescu
Latest posts by Eugen Mihailescu (see all)
- Dual monitor setup in Xfce - January 9, 2019
- Gentoo AMD Ryzen stabilizator - April 29, 2018
- Symfony Compile Error Failed opening required Proxies - January 22, 2018