Ok but those were separated over multiple posts, thus they weren't as disruptive. Estimating the life expectancy of an external hard drive involves knowing several key pieces of information.

If you're a consumer, you need to know who manufactured the hard drive, what the model number is, and then you have to track down the MTBF (Mean Time Between Failure) data publshed for that hard drive, if there is any published, for example.

If you're the manufacturer, you know the MTBF of the components you're putting into the hard drive, and put those into a statistical formula to find a probability curve for when you can expect failures to occur.

The MTBF will tell you when you can expect the hard drive to most likely fail in normal service.

The overall failure frequency usually forms something called a Bathtub Curve — found by combining the rate of random failures, "early" failures (caused by manufacturing defects and design defects), and end-of-life failures (physical parts wearing out, electronics failing — the MTBF). The rate of failure is high at the beginning and end of the hard drive model's service life, so the curve resembles a bathtub cross-section.

Why aren't they repairable? Sometimes they are — when what fails is the electronics of the hard drive. Hard drive recovery shoppes will remove the controller boards from the hard drive and replace them with a known good controller board from the same model and manufacturing run, and sometimes be able to salvage what's on the drive that way, because what failed was a resistor or capacitor or chip.

More often, the failure of a hard drive is due to the read-write head of the hard drive failing — and when they fail, they usually scratch up and destroy the surface of the hard drive platter.

If that occurs, you'd effectively need access to a hard drive manufacturer's R&D department to have even a remote chance of salvaging that data.

The service life of any rotor-based hard drive (has a spinning platter and read-write head) is shortened with exposure to temperature differentials (making it warmer, making it colder) startups and shutdowns (spinning up the disks and spinning them down again), time spent spinning (eventually the motor bearings will wear out), and vibration and shock encountered (even shouting loudly in a data center can negatively effect the ability of the hard drives in it to read and write data to and from disk). So knowing whether those happen help estimate service life, and that is what the S.M.A.R.T. protocol tracks.

Ubuntu, I'm not 100% certain (I could get certain — my netbook five feet away runs it) — but I know for certain the zip utility in OSX is configured to only open one level deep on zip files, for this exact reason.

If you know the command line arguments to tell the zip utility program to yes, really, don't question it, just unpack every nested zip file down automatically — you'd eventually either hit your user storage quota (if configured) or run out of disk space on that file system container.

And because system swap is in an entirely different logical (if not physical) file hierarchy/volume/partition from userspace, all that happens is you can't make more files until you delete some stuff.

I think it's still possible in Windows8 default configurations to kill the system and keep it from booting by filling the system partition's file tables / storage space strategically. I know it's possible for malware to encrypt the entire thing...

In macosx, the drivers for mounting filesystems run in a privileged mode, in order to ensure the performance of the drivers - so that they can't be pre-empted by applications demanding processor time, for example. They always get priority.

When disks go missing unexpectedly, the OS can't just initiate cleaning up the systems set up to handle the I/O for that disk - it has to wait out the drivers all timing out and returning their error codes up the line to the kernel, and once all that happens, then it can go about cleaning up and handling errors.

Further, if the disk is ejected improperly, the filesystem may be "dirty", improperly cleaned up and organised, and may be missing data. OSX' FAT32 system just reads and writes FAT32, it doesn't have much in the way of handling recovery of dirty FAT32 filesystems (and nothing in the way of recovering dirty NTFS systems).

Filesystem access that isn't run in this privileged mode is better able to handle irregularities and unexpected states - and the PlayStation and Parallels both do that.

Finally, the drivers for FAT32 access on OSX aren't programmed by Microsoft, they're programmed according to Microsoft's published specifications for FAT32 - which makes them by-the-book, and unable to use the kind of inside knowledge of the system that Windows' drivers have coded into them (including dirty filesystem recovery, as mentioned).

The workaround for this is to copy off all the data from those affected drives, re-partition and re-format them, and copy the data back, and don't yank drives.

The estimation of the service life of a router is much like any other piece of electronics, as described above.

I hope this clears things out