An amusing account

B-Con · 2008-04-30 00:07:48

Just a helpful tip to would-be script writers out there: It is advisable to examine your script before you run it. I learned this lesson the hard way recently.

Before the upgrade to v2.22, the Gnome desktop environment kept each user's "trash can" in the folder ~/.Trash. Performing a "soft" delete of a file merely moved the file to the trash can, where it would await permanent deletion.

Being a security-conscious person, I made a habit of shredding my deleted files when I emptied the trash. Since there exists no built-in feature to do so, I wrote my own simple script to do it for me, as follows.

#!/bin/bash

# Empty the "trash"
cd ~/.Trash
shred -n 3 *
sync
rm -rf *

It performed its elementary task perfectly.

However, when Gnome upgraded to v2.22, the location of the trash can changed (for better compliance with the FreeDesktop.org standards) to ~/.local/share/Trash. In this folder exist two folders, "files" and "info", which contain the actual deleted files and info for their undeletion, respectively.

So I had to upgrade my script to shred the new trash can. At the same time I decided to add an option to empty the trash without shredding the files because sometimes I would have large non-sensitive files (such as Linux distro ISOs) that I didn't care to spend time shredding. So I rewrote my script in less than a minute to this:

#!/bin/bash

# Empty the "trash"
if [ "$1" = "shred" ]; then
    cd ~/.local/share/Trash
    shred -n 3 files info
    sync
fi
rm -rf files info
mkdir files info
chown b-con:users files info

Since I was working on various other school/personal projects, I made the changes without thinking too much about it and quickly moved on to other tasks.

If you have any experience with programing, a quick glance through that revised script should raise a serious red flag.

That's right, my script only changed into the trash directory if I was performing the shred operation. If I was not performing the shred operation, it did not change directories and merely deleted "files" and "info" from my current directory. I had placed one line of code just one line too low.

I suppose it goes without saying that in my home directory I keep a folder called "files". This is where I store dozens of miscellaneous files, such as half-finished writings for this website. The first time I executed the script without the "shred" option while in my home directory, which was that very day, the contents of my "files" folder disappeared.

When I noticed what had happened several days later, I nearly had a heart attack. I spend a long time looking through various logs and my bash history, trying to determine what had happened. I was mad that something had the audacity to touch files in my home folder. I was ready to strace every binary on my system. However, seeing the presence of the new "info" folder eventually sparked my memory and I realized what had happened. Needless to say, I felt more than just a tad embarrassed.

I recovered just about everything from a lucky three-week-old backup I had made by chance, so all ended well. But still, that's one lesson I'll not soon forget: Always proof-read your bloody code, even just briefly.

brebs · 2008-04-30 00:37:46

It should be: cd wherever || exit 1

B-Con · 2008-04-30 02:19:14

Indeed. And it is in my local script, I've since added to it.

sujoy · 2008-05-10 11:16:59

quite a lesson.

finferflu · 2008-05-10 11:37:03

I am very paranoid about scripts involving the command "rm", so I usually execute them in a sterile environment, a folder with fake (touched) files, and only after testing thoroughly I use them.

I have deleted too many important files because of my mindlessness, I think I have learnt my lesson

11010010110 · 2008-05-10 13:41:04

When I started reading I thought of another failure mode : running the 1 st script (./Trash) after the Gnome upgrade

cd ~/.Trash fails since the folder does not exist
shred -n 3 * we are in the home folder
sync
rm -rf * we are in the home folder

This can be prevented by use of rm -rf ~/.Trash/* instead of cd and then rm -rf *

Check if the new scipt may fail like this if the folder does not exist

Cerebral · 2008-05-10 22:51:50

11010010110 wrote:

Check if the new scipt may fail like this if the folder does not exist

Brebs already brought that up, although you walk through why it's such a big deal, which may help people understand the issue.

brebs wrote:

It should be: cd wherever || exit 1

.:B:. · 2008-05-11 01:00:34

Doesn't shift + Del work in Gnome's file manager? It does in Thunar, and it does in Windows .

11010010110 · 2008-05-11 19:48:45

Its like rm but not like shred

B-Con · 2008-05-13 10:49:17

While we're on the topic...

It's something like 2:30am and it's been a bit of a long day. I'm doing a much needed -Syu ("much needed" here meaning "it's been a couple days") and I decided to take a quick look in /etc/ to see what .pacnew or .pacsave files I've forgotten to cleanse out as of late.

However, upon cd'ing to /etc, I remember that I took care of all the .pacnew's just a day or two ago, so I can delete any existing ones.
$ sudo rm *.pacnew

In my defense, I have to say it was 2:30am and I would never in my right mind issue a "sudo rm *" for any reason other than to wipe out a folder.

Those of you familiar with the concept of "irony" have no doubt already guessed that I hit the spacebar a wee miss-timed, and actually issued a
$ sudo rm * .pacnew
instead. Say bye-bye /etc/ . Needless to say, I got very much of nowhere without my passwd.

Thankfully I didn't touch the folders, which is where the real important stuff (xorg, etc) is.

I'm in the process of (successfully) recovering/rebuilding my /etc. I keep my laptop with virtually an identical install as on my desktop, so I've transported the /etc from my laptop to my desktop and edited various files (fstab, passwd) till it all works. Thankfully, a relatively small, small chore.

(Although now I'm wondering if some more important files couldn't have been recovered by using the "hard-line to inode" file recovery trick for processes with open files. Although I can't think of anything that keeps something like passwd or fstab constantly open.)

Gaaaaah, shoot me, please, somebody... before I do something *bad*...

(P.S. Old backup hdd failed a while ago and I never got around to replacing it. New one(s) will be ordered tomorrow. I hope I still have data to backup by the time they arrive.)

schivmeister · 2008-05-13 12:42:50

finferflu wrote:

I have deleted too many important files because of my mindlessness, I think I have learnt my lesson

Same here Now I just live with interactive rm and mv, and move stuff to a folder first before deleting at the end of the week - if i remember.

Last edited by schivmeister (2008-05-13 12:43:48)

Bison · 2008-05-13 12:59:33

it would be safer to use find

find ~/.local/trash -type f | xargs rm

Arch Linux

#1 2008-04-30 00:07:48

An amusing account

#2 2008-04-30 00:37:46

Re: An amusing account

#3 2008-04-30 02:19:14

Re: An amusing account

#4 2008-05-10 11:16:59

Re: An amusing account

#5 2008-05-10 11:37:03

Re: An amusing account

#6 2008-05-10 13:41:04

Re: An amusing account

#7 2008-05-10 22:51:50

Re: An amusing account

#8 2008-05-11 01:00:34

Re: An amusing account

#9 2008-05-11 19:48:45

Re: An amusing account

#10 2008-05-13 10:49:17

Re: An amusing account

#11 2008-05-13 12:42:50

Re: An amusing account

#12 2008-05-13 12:59:33

Re: An amusing account

Board footer