Alright, I'll bite some more:
The "don't be careless" position would be fine, but it's akin to never making any mistake, which, considering the amount of background cursing noise experienced in any IT profession, is the exception rather than the rule. If you've never been careless when working with computers then kudos to you, but I don't think that's the general rule. Oh, and I don't think I mentionned using rm as root (but of course, you want to be root to umount the filesystem and revent further writes after you realized your mistake).
For the sake of what follows, let's consider that I, stupidly or not, as a non root user, innadvertently deleted that 10 GB worth of irreplaceable data I just generated (eg that 10 GB HD video file of an UFO landing on my front lawn). This was my only copy. Now let's consider the options:
- 'rm' alias, a.k.a. as the Windows-like trashcan: That solution would be fine if I didn't (usually) want to have that file space freed straight away. If I remvove a 10 GB file from my system, I want 10 GB more disk space available => not the best option. Plus what if that file just got deleted from an UI (eg. the video editing app I was using under X) rather than from an 'rm' command. Also defuses the careless argument with "what if I am the most careful person in the world, but I am using an application (which I carefully picked), that has a bug, which noone foresaw, that deletes large files using system calls"
- snaphots: This looks like the best compromise at the moment, but for that to work, snapshots would need to occur in real time. I might be wrong, but I don't think this is the case on ZFS right now => if I recorded that UFO landing video and lost it in the interval between snapshots, it doesn't really solve my problem
- undelete in userspace through something different than aliases: I've seen this advocated again and again, and it is my layman's opinion that undeletion does indeed belongs to the filesystem rather than userspace. All undeletion takes is a chained list of blocks (so let's say 8 bytes for 64 bit block addressing of the partition, to be safe). Give me 8 bytes/block of file data, and I can now scan the whole partition, retrieve all data that has not been overwritten, and recover it. If I umounted my partition right after I realized my UFO video was deleted, it won't be much of a problem to recover it. Don't care much about filenames and perms as long as I can peek into recovered files (or parts of files), but if you insist, I'll be creative an flip a single bit instead of 64 for blocks that are sequential, so that I can use the remaining 63 bits, over multiple sequential blocks, for stuff like unique ID, original filename, perms, etc. Won't do much for small files, or if a lot of write operations have intervened in the meantime, but if that wasn't the case, there's a good chance you'll be able to rebuild it almost in full, even with a few missing blocks here and there
Now, I'll agree that not everybody wants to lose 8 bytes/block, but then mkfs could give undelete as an option on FS creation, and as long as people have a choice, everybody's happy...