equals to:

one neat function of the find command, it that what it found can be passed to another program for further processing.

or: it can delete the file by adding the option -delete

BUT (!!!) THIS IS DANGEROUS! as things can go horribly wrong (and it does not ask for confirmation), in the worst case: deleting EVERYTHING in the current directory within the blink of an eye (depending on systems speed… terrabytes of data within seconds).

# warning! this can ruin one's day

mkdir temp
cd temp
touch 1 2 3 f25020672.avi

# only finds that file
find . -name "*f25020672.avi*"
./f25020672.avi

# DANGER! THIS DELETES

# ALL (!!!)

# FILES IN THE CURRENT DIRECTORY! (NOT ONLY THE -name “*FILES*” SPECIFIED )

find . -delete -name "*f25020672.avi*"

# this would have been the correct way to do it
find . -name "*f25020672.avi*" -delete

guess will have to powerdown, and continue when the backup-system of the backup-system is ready X-D

those are the times – when ext3 is better than ext4 (extundelete can WITH EASE recover the files INCLUDING THE FILENAMES, under ext4, no filenames, without filenames and paths… it’s hard to identify what file is what)

why? (actually)

because find does argument “left to right” processing and regards -delete as an action (-name stands for action “just print the damn filenames”)

as soon as it finds an “action” argument, it will spring into “action” and delete ALL your files no matter what argument comes after the action argument (a -name argument for example).

asked the users @ https://www.gnu.org/software/findutils/

the answer was: will improve the manpage “great”

comment: but the UNIX philosophy is to simplify, simplify, simplify,and pretty much follow that principle and it works wonders 🙂

what about simplifying the usability & build in fail safes?

so everyone here says it is intended behavior that find -delete -name “*searchforthis*” just deletes everything under the current dir .

ok, guess there will have to be a find2 then

this intended behaviour by find forces users to transition from ext4 to zfs or btrfs and will still cost 3 years of sorting 1 million photorec restored jpg (without the filenames) by hand (until an AI comes up and does the job)

so cu in 2025

undelete?

on ext3, this is no problem, on ext4… photorec can restore photos, but not filenames… so probably a major problem…

ext3undelete ext4undelete extundelete linux undelete recover deleted files – extundelete Bad magic number in super-block when trying to open filesystem – DO NOT ATTACH EXTERNAL USB-SATA HARDDISK DIRECTLY TO SATA

GNU Linux – recover deleted files NTFS – undelete ext3 vs ext4 – rescue accidentally deleted data files – overwritten partition table – foremost – gpart

admin