Robert,

One other suggestion.

FRANCHISSEUR Robert wrote:
> This is what I did (as root):
> 
> cd /mirror_disk/sauvegarde/data
> time find . -exec shred -n 3 -z -u  {} \;
> 
> on a directory of ~ 14 Gb in a 1 Tb firewire external disk
> mounted on /mirror_disk/
> 
> The command did what I expected but I discovered that several 
> other files in other partitions were *EMPTIED* !!!
> 
> For example, among others:
> 
> cd /; find . -type f -size 0  -printf " %t %s " -print

Rather than use the dot (.) for specifying where you what find to start 
working from, spell out the directory where you want it to start.  This 
is especially true when running a command that removes files/data and 
running as 'root'.

Imagine if I type:

cd /afs/fnal.gov/<some_unreachable_directory>; find . { and then the 
rest of the command.

If the directory that I tried to CD into is not accessible for any 
reason, that 'cd' command will fail.  Then the 'find' command will start 
running from whatever directory I am currently in.  This can be a very 
bad thing.  Everyone makes that mistake once in their life.  You have 
been warned. :-)

Also, there is an option on the find command which will limit the files 
found to the filesystem where you begin your search.  While this is 
quite useful, I don't know if it will help with the 'shred' command.  As 
someone else pointed out, it appears that 'shred' followed some links 
and did it's clean-up work.  Using the option that limits the scope of 
the find will not place any limits on the scope of 'shred'.

Ken S.