You stopped short of using all the available default aliases:

ls | ? {$_.Length -lt 10mb} | del

Also, doing it recursively is 3 more chars:

ls -r | ? {$_.Length -lt 10mb} | del

“why didn’t you just order the files by size in Explorer and hit delete”

Probably would have been slower anyway. Explorer’s search/sort functionality is a bear to work with and this way you have to wait twice rather than once.

I’ve done this kind of work before as well. I reconcile 20TiB of video files, including backups, backups of backups, and incremental work files. I wrote a lisp programs which hashed the files to determine uniqueness and grouped them based on tag and path information. I was able to quarter the filespace to be archived. They went ahead and archived the whole damn thing anyway. Librarians…

I was once asked to recover files from a failed drive. They had managed to use some sort of autorecovery tool, but it not only cleared the folder structure like yours, but also cleared the filenames. Every single file had a hash-like name, and they were in the same directory.

I wrote a script that tries to guess the file type ($(file)), creates new directories for the filetypes (“/images”), and writes a ‘better’ name and an extension (“/images/image_001.jpg”) so that the owners could open the files without guessing the filetypes themselves.

@ Chris Wellons:

That’s actually an excellent point. I didn’t think about that, but yeah – if you don’t want to back something up, it is good idea to keep an up-to-date file index just so that in an event of a catastrophic data failure you know what you have lost.

You could say that while all the file data on the drive was easily replaceable, there was still some important, hard-to-replace data on the drive: the file listing. It’s like losing all your bookmarks. The data is all out there but you lost the directions to get to it.

This information could be captured and backed up with a simple “find /mnt/archive > listing.txt“.