all files in /home/user/ vanished (deleted?)

Hi,
so well, except for 6 directories, all other files and directories in my /home/user/ directory are just gone. The mentioned 6 directories have their change time set to the exact same time, but are empty (all files in this folders are also gone).

What I did:
on desktop1 I opened dolphin in one of my dirs, rightlicked a scriptfile (few lines, containing some echos, scaimage and convert), picked “open with Kate”. I have Kate already opened with a simple textfile on desktop2. KDE switches to desktop2 and kate, shows the file, but it is empty… (which should not be). At first I thought I opened the wrong file, switched by to desktop1 and… the dir opened in Dolphin was empty. Then I saw the Desktop and it is also empty… all files linked to there just gone.
Then I opened a terminal, using cd ~ and ls -l and… everything is gone, except for 6 directories, which on the other side, are empty as well now.

Since I am not a linux expert, I have not the slightest idea where to start looking/troubleshooting (and find all the files, that are gone).

Hope someone can point me in the right direction (I gues the files are for some reason just not visible, ls -la is not helping, because firefox have still all its settings and bookmarks and the profile-dir is also located in /homer/user/)

edit: skip the last sentence, I just noticed all the “hidden” folders and files were not touched and firefox settings are in /home/user/.mozilla

I assume that the directory name user you use above in /home/user/ is the username of the user that is loged in and that is having the problem? (giving a user the name user isn’t making things vvery clear imho :slight_smile: ).

And is the assumption correct that

ls -la $HOME

shows that all directories/files where the name starts with a . (dot) are still there?

user = general, of course for me its /home/mla/ sorry :slight_smile:
ls -la $HOME
shows all hidden files, all hidden directories (the contents of the hidden directories are still there), and it shows 6 non-hiddden directories, which are empty

Said script wouldn’t have contained any rm commands or similar that may have accidentally had the wrong path?

the last line of the script was(is)

rm /RAMDISK/*.pnm

If, for whatever reason, openSUSE executed the script while opening it in a texteditor, and if the rm command parameters were ignored (targetdir and actualy not recursively), then the question is, how do I recover the deleted file? I doubt it is as easy as in windows.

I was also thinking along the same lines as Miuku.

But when you only shhow one line of your script, that will not help much when others should analyze it. Remember that you NOT seeing where it goes “wrong” does not mean that others wouldn’t see it. The writer/owner/maintainer of a program always has some blindness in running through the same loop agian and again. A fresh eye/mind will then probably see things.

Analyzing those 6 names that are still ther might be interesting also.

And for your deleted files, restoring them from your (or the systems) backup is the fatstest way.

The reason I asked you about the rm is because even a space in the command in the wrong place may accidentally execute it in your “default path” (which would be your home).

Also, did the command have any move commands that could have moved the files to another location, such as /tmp ?

You’ve (without a doubt?) checked Trashcan already?

There are ways to recover data from ext4, such as Testdisk or extundelete but under no circumstance should you write anything to the drive as it may overwrite the data you are trying to recover.

Now that explains a lot, thanks! If the script got somehow executed by accident, the parameters were missing (blanks?) and thus could delete the default path, line 21? (could recover the script, sorry no linux expert and only had to remember the script from last time I saw it, … well, already (hours ago) unmounted the device in question, and making it suffer from dd and ext4magic.

here the script


#!/bin/bash
#v1.1

umask 0000

#parameter
COLOR=${1}
X=${2}
Y=${3}
DPI=${4}
SCANNERDEVICE=${5}
DUPLEX=${6}
CONTINUOUS=${7}
QUALITY=${8}
TMPDIR=${9}
FILENAME=${10}

PAGELAYOUT="-x $X -y $Y "

rm -r $TMPDIR/* > /dev/null 2>&1

echo "Farbtiefe: $COLOR"
echo "X+Y: $PAGELAYOUT"
echo "DPI: $DPI"
echo "SCANNER: $SCANNERDEVICE"
echo "fortlaufend: $CONTINUOUS"
echo "Qualitaet: $QUALITY"
echo "Temporaerer Dateiordner: $TMPDIR"
echo "Dateiname: $FILENAME"
echo ""

case $CONTINUOUS in
    1)
    BATCHCOUNT=""
    ;;
    0)
    case $DUPLEX in
        1)
        BATCHCOUNT="--batch-count=2"
        ;;
        0)
        BATCHCOUNT="--batch-count=1"
        ;;
    esac
    ;;
esac

case $DUPLEX in
    1)
    echo "duplex"
        echo "scanimage --mode $COLOR $PAGELAYOUT --resolution $DPI -d $SCANNERDEVICE --batch=$TMPDIR$FILENAME-%02d.pnm --batch-start=1 $BATCHCOUNT --source ADF Duplex"
    scanimage --mode $COLOR $PAGELAYOUT --resolution $DPI -d "$SCANNERDEVICE" --batch="$TMPDIR$FILENAME-%02d.pnm" --batch-start=1 $BATCHCOUNT --source "ADF Duplex"
    ;;
    0)
    echo "simplex"
        echo "scanimage --mode $COLOR $PAGELAYOUT --resolution $DPI -d $SCANNERDEVICE --batch=$TMPDIR$FILENAME-%02d.pnm --batch-start=1 $BATCHCOUNT"
    scanimage --mode $COLOR $PAGELAYOUT --resolution $DPI -d "$SCANNERDEVICE" --batch="$TMPDIR$FILENAME-%02d.pnm" --batch-start=1 $BATCHCOUNT
    ;;
esac

for i in `ls $TMPDIR`
    do
    zaehler=`echo $i | cut -d "-" -f2`
    zaehler=`echo $zaehler | cut -d "." -f1`
    suffix=".jpg"
    echo "Konvertiere Datei=$FILENAME-$zaehler.pnm zu $FILENAME-$zaehler$suffix"
    #convert -quality $QUALITY -resize 826x1100 "$TMPDIR$FILENAME-$zaehler.pnm" "$TMPDIR$FILENAME-$zaehler.jpg"
    convert -quality $QUALITY "$TMPDIR/$FILENAME-$zaehler.pnm" "$TMPDIR$FILENAME-$zaehler.jpg"
        #convert -unsharp 0x1 "$TMPDIR$FILENAME-$zaehler.jpg"
    echo "loesche Datei=$FILENAME-"$zaehler".pnm"
        rm $TMPDIR/$FILENAME-$zaehler.pnm
done

Well,

rm -r $TMPDIR/* > /dev/null 2>&1

looks rather dangerous to me.

When you like to go for serious programming, then you must learn that cheking all parameters comming from outside is a very important security thing to do. IMHO a high percentage of cracking is due to sloppy testing of parameters.

Be glad you did not run this while being the Superuser.

Aye, another lesson that was worth it, and thanks for the infos.
A linux-guy gave that to me and said nothing about “dangerous”…

On 07/15/2014 05:16 AM, mlarue wrote:
> rm -r $TMPDIR/* > /dev/null 2>&1

This is probably the line that killed you. Without specifying the ninth
argument/parameter to your script this ran as ‘rm -r /’.

If you had accidentally executed this as ‘root’, you wouldn’t have a
system anymore.

Sanity checking at load time is a good thing. For example:


usage () {
echo 'Put in ten arguments.  Here are some hints...';
exit;
}

if  -z ${10} ]]; then
usage
fi


Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below…

Yeah I agree with hcvv, the TMPDIR parameter was your home directory and it ran the rm -r command there. Stuff like this happens - unfortunately in a system that gives you unlimited power, it also gives you the power to cause unlimited damage.

Live and learn. :slight_smile:

So the recovery is nearing its completion, unfortunately it consists of names like “RECOVERDIR/MAGIC-3/text/x-c/0007380800.c”. A lesson I am not going to forget. Thanks for your input.

It will not touch the / directory because the

$TMPDIR/ 

is not defined it will be empty so rm just ran

rm *

In this case inside “$HOME” however if you do

${TMPDIR}/ 

then surely it will do

rm  /*

Also using upper case variables for internal purposes is a disaster waiting to happen because all the internal builtin variables are uppercase already so expect more deleted files and directories in the future lol!.

Quote all your variables and please do not parse the output of **ls **a glob will suffice

files=(*)
printf '%s
' "${files@]}"

Or in your case with an extension

pics=(*.jpg)
for i in "${pics@]}"; do
   echo "**DO SOMETHING WITH** $i"
done

That’s incorrect.

If $TMPDIR is undefined, $TMPDIR/ will give / and “rm -r $TMPDIR/*” will run

rm -r /*

Which will recursively try to delete all files/directories on your system.
Of course when run as user it will not have permissions to remove everything, but it will in particular delete everything in $HOME of course.

If you don’t believe that, try to run:

ls $XXX/

or

echo $XXX/

I stand corrected about the trailing / and prolly ~ but most characters will not have the same result. Also if you qoute the * (globe) it will not expand too.

???
Of course most characters will not have the same result.

Only / is /.
And ~ expands to /home/user/.

Also if you qoute the * (globe) it will not expand too.

Yes, of course.

rm -r "$TMPDIR/*"

will not recursively remove all files/folders, probably none at all.

And if you write something completely different, it will do something completely different.
So what’s your point? :wink:

rm $TMDIR~

if TMDIR is undefined it will delete “$HOME” that is what im trying to say. Now what is your point?

TMPDIR=$9

then you want to add the “$DIR” variable and run rm on it

rm $TMDIR$DIR 

or add some character

rm $TMPDIRfoobarbazmore

will not have any result but if you use curly braces

rm ${TMPDIR}foobarbazmore

will have some results which AFAIK the OP is trying to do, add an additional variable.

Also the common mistake is to quote the globes because the shell variables requires to be quoted to prevent word splitting among other else.

$TMPDIR

should be

"$TMPDIR"

bu if you want to add the trailing slash / and a globe, the mistakes is easily done.

rm "$TMPDIR/*"

but of course you will not do that because you are a better man…