My environment: SLED 11 SP3 (patch level up-to-date) including Gnome 2.28.x, nautilus 2.28, GNOME Utilities 2.28.3
Right-clicking on the trash can shows its properties: 2.758 objects consuming 92,9 MB. The reason for this amount is that I replaced evolution with thunderbird because evolution and the provider’s software disagreed about the TLS stack. I copied too many evolution folder contents and afterwords deleted some of them.
When I try to open trash, it takes quite a long time, but nothing happens, no content is listed. That’s something new. A look into /var/log/warn shows timeout messages which might as well result from other processes. The only action offered to perform on trash is to empty it.
Any idea? Is there a default configuration limiting the number of trash objects or size of occupied space? If there are such limits, does anybody know where the configuration file resides? Is there any alternative way to view the trash content and erase only some of it?
Right-clicking on the trash can shows its properties: 2.758 objects consuming 92,9 MB. The reason for this amount is that I replaced evolution with thunderbird because evolution and the provider’s software disagreed about the TLS stack. I copied too many evolution folder contents and afterwords deleted some of them.
When I try to open trash, it takes quite a long time, but nothing happens, no content is listed. That’s something new. A look into /var/log/warn shows timeout messages which might as well result from other processes. The only action offered to perform on trash is to empty it. [/QUOTE]
And what do the messages in /var/log/warn say?
I’ve never heard of or encountered such a limit.
I just created 3000 files and put them in to Trash and I can open Trash fine.
[QUOTE=guennov;27797]
Is there any alternative way to view the trash content and erase only some of it?[/QUOTE]
You could try running
$ gnome-open trash:///
Or just look in ~/.local/share/Trash/ There are two sub-directories in there, files and info. files contains the files that have been move to Trash and info contains information about those files such as when they were put in Trash and their original location.
Files that have been moved to Trash from somewhere other than your home directory will be in a directory called .Trash-${UID} in root of the relevant partition. (UID being the UID of the user that moved the files to Trash. use ‘echo $UID’ to find your own UID’.
The origin of the timeout messages must have been other processes. Today there are none.
[QUOTE=mikewillis;27805]I’ve never heard of or encountered such a limit.
I just created 3000 files and put them in to Trash and I can open Trash fine.
You could try running
$ gnome-open trash:///
The response to the command was analogous to that using nautilus. After quite a long time waiting in the end no content was shown.
That’s a step towards of a solution. I had a look in Trash/files. Nothing seemed extraordinary except two red-coloured links. Using nautilus I successfully emptied Trash. Its subdirectories files, info, and expunged contained no more items. Then I started testing. With exactly one test file everything worked fine, Trash content looked as expected and I could restore the file. But Trash failed working with more than one file or with directories: I could not open Trash any more! No matter even if the directory I moved to Trash was empty or not.
Strange. No actual error messages in /var/log/warn. I had a closer look at earlier error messages today and discovered, that, every time a gnome login session starts, there are error messages
May 10 16:48:02 letta gdm-session-worker[10065]: WARNING: gdm_session_settings_load: lang = (null)
May 10 16:48:08 letta checkproc: checkproc: can not get session id for process 6735!
May 10 16:48:13 letta gnome-session[10860]: WARNING: Could not launch application '10d87900a2513cbbf9143126644483272600000065770025.desktop': Unable to start application: Kindprozess »slab« konnte nicht ausgeführt werden (Datei oder Verzeichnis nicht gefunden)
Translation of the last words: “child process »slab« could not be executed (file or directory not found)”.
Similar messages are logged independent of the user who opens a gnome session. Locale for some user is set to LANG=de_DE for example.
There are other peculiarities concerning gnome sessions which might help finding a solution for Trash too. For example after I switched to text mode (strg-alt-f1) sometimes alt-f7 offered a black screen instead of switching back. I had to invoke alt-f8 to switch back to graphical display. Another example for malfunctioning is the gnome screen saver. Long time ago I disabled it because instead of screen saving a bug buddy report concerning gnome-screensaver-helper locked the session and I had to switch to text mode and manually kill the session before I could go on. I forwarded the report to the respective developer group.
May be there is a general gnome installation or configuration problem?
slab could be a reference to the menu that’s on the bottom left of the panel invokable by clicking ‘Computer’ (or localised version of). It’s known as the slab menu, though for reasons I’ve never established the package that provides it is called gnome-main-menu
Does that message about 10d87900a2513cbbf9143126644483272600000065770025.desktop get logged for every user that logs in?
Might be worth finding out what 10d87900a2513cbbf9143126644483272600000065770025.desktop is. Try
If you don’t have the locate command install the package findutils-locate then run /etc/cron.daily/suse.de-updatedb Or
$ find /usr/ -type f -name 10d87900a2513cbbf9143126644483272600000065770025.desktop
This assumes the error about 10d87900a2513cbbf9143126644483272600000065770025.desktop comes up for any user that logs in so the file isn’t in the home directory of one user.
There’s clearly problems, question is are they caused by something at the user or system level. Do the trash and screen saver problems occur for all users? If only for one user delete that user’s ~/.gnome ~/.gconf directories and see if that helps. If for all users, well, had to say. Sometimes easiest solution is back up anything important and re-install.
What’s the output of
$ zypper refresh
$ zypper lu
$ zypper ve
$ zypper lr -u
Solution for the Trash problem was a faulty .profile. I had changed LANG to de_DE instead of the default value or de_DE.UTF-8. A closer look at .xsession-errors gave me the clue.