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.