On Mon, Jan 17, 2011 at 1:27 PM, Roger Searle <[email protected]> wrote: > /media/drive/2003/2003/2003 (repeat many MANY times) > /2003/somephotos.jpg. Attempting to do rm -rf may be doing something > (shows in htop, taking a few % of a core) but a few hours later is still > not done. Looking at the properties of the top level folder in a file > manager, it reads for ages trying to determine number of folders and > gets to a brick wall at about 140,000 folders and kills my KDE session!
So you have a structure of many directories, and at the bottom a set of files? Or something different? I presume you've removed the files at the bottom OK? > Any suggestions on how to remove the offending folders in some quick-ish > and recursive fashion are welcomed, while leaving other folders in > /media alone. Errm, unlink() the top one (/media/drive/2003/2003 ?) using perl or C or something that isn't the shell, then unmount and fsck the filesystem :-) Then go remove anything left in the /media/drive/lost+found directory ... That's a little dangerous though, but if you like living on the edge, go for it. Also, given that this is a backup drive, don't bother preserving the rest of /media/drive, consider nuking it completely with mkfs, and then re-establishing the backups. Not sure what caused your problem, but I like to leave marker files on my mount pounts, where they exist when a device is unmounted (i.e. not /media/...) So when my drive is unmounted I might have "/data" -- so in there I'll create a file called "/data/STOP". When the correct device is mounted onto /data, this file effectively disappears -- so I can check for it in the top of any simple backup scripts ... if [ -e /data/STOP ] then exit 1 fi This helps to detect unmounted directories, without having to know anything about how they are mounted in the script. -jim _______________________________________________ Linux-users mailing list [email protected] http://lists.canterbury.ac.nz/mailman/listinfo/linux-users
