OESF Portables Forum
Model Specific Forums => Sharp Zaurus => Zaurus - pdaXrom => Topic started by: ZDevil on January 22, 2007, 01:26:14 am
-
Just a moment ago I was using emelfm2 to delete stuff from my SD card which is the space for building things. There was an unwanted dir with around 200MB. So I simply dragged the whole thing to the trash box icon.
And then ... BOOOOOMB! I noticed something unusual in the resource monitor in the desktop panel, so in a few seconds I went to the shell to kill emelfm2.
The funny thing is: I didn't know where the huge trashed dump went!
All I saw right after that was the internal space got almost filled up, with only around 1MB left. I suspected the dump directly went to the internal flash. After using the find -size ... command in vain and rebooting, I still failed to trace the dump or solve the problem.
Quite surprisingly, there seems to be no manual for emelfm2 GUI online!
Opening up the source of emelfm2 I saw a doc/usage. And it says,
TRASH
When e2 puts something into trash, it will first try to use a folder named '.Trash' in the directory the item(s) come from i.e. the one shown in the active pane. If such a folder doesn't exist, fallback choices are: '.Trash' in the user's home directory, then finally, '.emelfm2/Trash' in the user's home directory. The last of these will be created if it didn't exist already.
There is no over-write checking for trashed items. Any item with the same name, already in the trash, will simply be erased.
However there was simply no .emelfm2/Trash or .Trash created anywhere in the system.
Desperately, I searched the web again and saw the emelfm2 man page (http://www.die.net/doc/linux/man/man1/emelfm2.1.html) at last. Under the "command line options" it says,
-t,--trash= DIR
Set the trash directory to DIR (default: ~/.local/share/Trash/files).
That's the correct path. The partial chunk was really there. Removing it freed up the internal space again. Then I removed emelfm2 to help stay away from further troubles.
The trash thing may not be considered to be a bug of the program, but using it for devices with little internal space perhaps a bit caution is needed.
Or am i the only delusional one?
-
Just a moment ago I was using emelfm2 to delete stuff from my SD card which is the space for building things. There was an unwanted dir with around 200MB. So I simply dragged the whole thing to the trash box icon.
And then ... BOOOOOMB! I noticed something unusual in the resource monitor in the desktop panel, so in a few seconds I went to the shell to kill emelfm2.
The funny thing is: I didn't know where the huge trashed dump went!
All I saw right after that was the internal space got almost filled up, with only around 1MB left. I suspected the dump directly went to the internal flash. After using the find -size ... command in vain and rebooting, I still failed to trace the dump or solve the problem.
Quite surprisingly, there seems to be no manual for emelfm2 GUI online!
Opening up the source of emelfm2 I saw a doc/usage. And it says,
TRASH
When e2 puts something into trash, it will first try to use a folder named '.Trash' in the directory the item(s) come from i.e. the one shown in the active pane. If such a folder doesn't exist, fallback choices are: '.Trash' in the user's home directory, then finally, '.emelfm2/Trash' in the user's home directory. The last of these will be created if it didn't exist already.
There is no over-write checking for trashed items. Any item with the same name, already in the trash, will simply be erased.
However there was simply no .emelfm2/Trash or .Trash created anywhere in the system.
Desperately, I searched the web again and saw the emelfm2 man page (http://www.die.net/doc/linux/man/man1/emelfm2.1.html) at last. Under the "command line options" it says,
-t,--trash= DIR
Set the trash directory to DIR (default: ~/.local/share/Trash/files).
That's the correct path. The partial chunk was really there. Removing it freed up the internal space again. Then I removed emelfm2 to help stay away from further troubles.
The trash thing may not be considered to be a bug of the program, but using it for devices with little internal space perhaps a bit caution is needed.
Or am i the only delusional one?
[div align=\"right\"][a href=\"index.php?act=findpost&pid=151989\"][{POST_SNAPBACK}][/a][/div]
--trash=/dev/nullwill fix it
-
--trash=/dev/nullwill fix it
[div align=\"right\"][a href=\"index.php?act=findpost&pid=151991\"][{POST_SNAPBACK}][/a][/div]
Thanks. I have to admit that I was acting in panic and I don't even bother to look at the interface again. Despite the many buttons in the GUI panels, is it a bit tricky to specify the trash path with a command line option? Perhaps that option should be made much more obvious to the user. (or maybe it can actually be set somewhere in the menus,... well, I have switched back to Rox filer now)
And i'm afraid your trick is something we can do only if no real trouble happens, e.g. the internal space is already fully filled up by the trash files and the system crashes ...
-
--trash=/dev/nullwill fix it
[div align=\"right\"][a href=\"index.php?act=findpost&pid=151991\"][{POST_SNAPBACK}][/a][/div]
Thanks. I have to admit that I was acting in panic and I don't even bother to look at the interface again. Despite the many buttons in the GUI panels, is it a bit tricky to specify the trash path with a command line option? Perhaps that option should be made much more obvious to the user. (or maybe it can actually be set somewhere in the menus,... well, I have switched back to Rox filer now)
And i'm afraid your trick is something we can do only if no real trouble happens, e.g. the internal space is already fully filled up by the trash files and the system crashes ...
[div align=\"right\"][a href=\"index.php?act=findpost&pid=151992\"][{POST_SNAPBACK}][/a][/div]
just add that option to the desktop file so each time you start emelfm2 it has that option.