Written by drinkypoo the 9 May 08 at 19:26.

Ubuntu Brainstorm was updated in January 2009. Since the idea #8301 was submitted before this update, its rationale and solution are not separated. Please vote accordingly, and if you have the necessary rights, please separate the rationale from the solution. Thanks!

<i>Ubuntu Brainstorm was updated in January 2009. Since the idea #8301 was submitted before this update, its rationale and solution are not separated. Please vote accordingly, and if you have the necessary rights, please separate the rationale from the solution.</i><br /> Thanks!

Written by drinkypoo the 22 Jun 08 at 12:51.

Ubuntu Brainstorm was updated in January 2009. Since the idea #10169 was submitted before this update, its rationale and solution are not separated. Please vote accordingly, and if you have the necessary rights, please separate the rationale from the solution. Thanks!

<i>Ubuntu Brainstorm was updated in January 2009. Since the idea #10169 was submitted before this update, its rationale and solution are not separated. Please vote accordingly, and if you have the necessary rights, please separate the rationale from the solution.</i><br /> Thanks!

Written by komputes the 6 Oct 09 at 01:06.

Apport needs to have a way of saving crash reports/ubuntu-bug/apport-collect to a file/folder when offline.

I suggest using bug program which can queue bug reports and allow you to write a subject and a description of the bug as well as attach more files while offline (or online). This will allow for quick bug submission from the desktop.

Apport needs to have a way of saving crash reports/ubuntu-bug/apport-collect to a file/folder when offline. I suggest using bug program which can queue bug reports and allow you to write a subject and a description of the bug as well as attach more files while offline (or online). This will allow for quick bug submission from the desktop.

Written by drinkypoo the 13 May 09 at 20:10.

The unlink() function call is provided by the C library, and it could be extended to permit the use of a simple user-space program to implement the trash can. If this program is not found, the file is simply unlinked as always, and the system proceeds as normal. If it is present, then it decides which files are trashed and which ones are simply deleted. For example, by default all files in /tmp or ending with ".temp" or similar will simply be removed.

If more files are kept instead of being deleted, the trash needs to be emptied more often. Whenever an attempt is made to allocate disk space, before actually failing the operation due to inadequate free store, an attempt could be made to remove files from the trash automatically, again based on the user's preferences so that inconsequential files are deleted first. Such functionality has the potential to prevent the user from EVER having to manually empty the trash, and also completely eliminate the need for undelete utilities — if the file can be recovered, it is already waiting for you in the bin.

The unlink() function call is provided by the C library, and it could be extended to permit the use of a simple user-space program to implement the trash can. If this program is not found, the file is simply unlinked as always, and the system proceeds as normal. If it is present, then it decides which files are trashed and which ones are simply deleted. For example, by default all files in /tmp or ending with ".temp" or similar will simply be removed. If more files are kept instead of being deleted, the trash needs to be emptied more often. Whenever an attempt is made to allocate disk space, before actually failing the operation due to inadequate free store, an attempt could be made to remove files from the trash automatically, again based on the user's preferences so that inconsequential files are deleted first. Such functionality has the potential to prevent the user from EVER having to manually empty the trash, and also completely eliminate the need for undelete utilities &mdash; if the file can be recovered, it is already waiting for you in the bin.

Written by kpeiruza the 14 May 09 at 16:48.

This command might implement the common "rm" options, so scripts will be able to use it without any change.

We can call it "tm" (trash-move) :D

Through /etc/alternatives/ you could point "rm" to the default "rm" command or to this "tm" command, keeping the whole system compatible and fooling any shellscript you have to perform moving to trash when attempting to delete stuff.

Solution #1 isn't practical, as it requires ALL PROGRAMS WRITTEN EVER TO BE CHECKED!!!! if your temporary files don't match your criteria (/tmp && .temp), they will be moved to trash!!!

This way we don't need to alter libc, the "second" core of our system. Figure out what unexpected incidents will you find out if you modify the unlink() function.... testing would take a year!!!

I think this might fix most of your problem whilst keeping libc standard through all systems that use it (*BSD, HURD.....), and reducing development times, bugs and testing drastically.

Of course, this will not work with software that doesn't use the "rm" command and goes straight to unlink(). I don't think moving all to trash is a good idea, I code loads of scripts and 95% of times I use unlink() is to delete temporary files, which usually end in the pid's number ($$), you can't force all world's coders to stick to a new standard because some people likes the trash-bin. I don't.

This command might implement the common "rm" options, so scripts will be able to use it without any change. We can call it "tm" (trash-move) :D Through /etc/alternatives/ you could point "rm" to the default "rm" command or to this "tm" command, keeping the whole system compatible and fooling any shellscript you have to perform moving to trash when attempting to delete stuff. Solution #1 isn't practical, as it requires ALL PROGRAMS WRITTEN EVER TO BE CHECKED!!!! if your temporary files don't match your criteria (/tmp && .temp), they will be moved to trash!!! This way we don't need to alter libc, the "second" core of our system. Figure out what unexpected incidents will you find out if you modify the unlink() function.... testing would take a year!!! I think this might fix most of your problem whilst keeping libc standard through all systems that use it (*BSD, HURD.....), and reducing development times, bugs and testing drastically. Of course, this will not work with software that doesn't use the "rm" command and goes straight to unlink(). I don't think moving all to trash is a good idea, I code loads of scripts and 95% of times I use unlink() is to delete temporary files, which usually end in the pid's number ($$), you can't force all world's coders to stick to a new standard because some people likes the trash-bin. I don't. Just figure out the volume of trash you can get into your trash-bin if you intercept unlink()!!!!!!!!!!!!! If you have such a problem, make regular backups or use a COW/Versioning filesystem :D