SlackwareThis Forum is for the discussion of Slackware Linux.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
My understanding is that, much like the DEL command in DOS, it deletes all reference to the file from the file allocation table (or Linux equivalent), not just moving the file to a temporary 'trash' location. Once you've rm'ed something, you're done.
About the only way you can have a "Trashcan" equivalent in Linux is to alias the "Delete" command to a "Move" operation instead.
You could get pretty sophisticated with it, mind you. A bit of shell script work could make a 'trash' command that:
- Stores a trashed file's original permissions and locations in a log somewhere
- Sets all trashed files permissions to 400 so nobody can snoop your Trashed stuff
- Deletes Trashed files after a certain length of time
- And is paired up with an 'untrash' command that'll restore the file to its original location & permissions by reading the Trash log
But at the end of the day, it'd be a lot of work.
Mind you, rm'd files CAN sometimes be restored. If you want to make absolutely sure a file is gone when you delete it, take a look at the 'shred' app - this repeatedly over-writes the file contents with random data, making it a very secure deletion application.
Originally posted by numb I will look into 'shred' app.. ty
One note, shred is not effective with journaling filesystems like reiserfs.
From the shred man file:
CAUTION: Note that shred relies on a very important assumption: that the filesystem overwrites data in place. This is the traditional way to do things, but many modern filesystem designs do not satisfy this assumption. The following are examples of filesystems on which shred is not effective:
* log-structured or journaled filesystems, such as those supplied with
AIX and Solaris (and JFS, ReiserFS, XFS, Ext3, etc.)
As far as I know, no shred-like deletion program is effective with journaling filesystems. I used to use shred, but stopped after moving away from ext2.
If you want a "recycle bin" or "trash can" like rm script, you could rename /bin/rm and create a shell script in its place. What the shell script would do is move whatever you want to remove into your desired holding place (e.g., ~/Desktop/Trash in .kde, etc.). Or, because other programs rely on /bin/rm for their functions, name your new shell script "trash"
BTW I think some filesystems actually have routines which write over the file rather than simply remove the hard links (reference/directory entry). I haven't gone through the source so I couldn't tell you which file systems do and do not do that. I'm fairly certain UFS does though (not used often with Linux but is often used with Solaris and OS/X)