All modern operating systems write hidden and sometimes not-so-hidden data to hard drives as soon as the drive is plugged into a host computer and powered on. This behavior upon disk mount is done automatically and typically without any user consent. Hidden folders like "Recycle Bin" (Windows) and "Trashes" (Mac OS X) are created/updated automatically. Spotlight or Windows search database indexes and graphical icon databases are created/updated. The "last touched" or "last accessed" timestamps on files and folders are updated automatically when merely browsing the drive. There's actually quite a bit of behind-the-scenes stuff that operating systems perform on data that they manipulate on every connected hard drive, regardless of how many settings are tweaked trying to turn those "features" off. Although most of this operating system cruft is presumably well-intentioned, it can cause compatibility problems when shuttling the drive between machines.
Lurking beyond the operating system mechanics are more insidious threats to hard drive data integrity. An undetected virus residing on the host machine can wreak havoc on client drives, writing copies of itself on every connected drive and corrupting data along the way. There's also the ever-present likelihood of "user error" — accidentally deleting the wrong file or formatting the wrong drive. No matter how carefully one treads when juggling multiple hard drives, dragging-and-dropping files or hammering away at the command line, Murphy's Law eventually and gloriously prevails.
So how can one guarantee that their studio system doesn't alter a single bit on incoming client hard drives? The answer is to use a hardware write blocker, a single-purpose device that sits in the middle and acts like a firewall, blocking all "write" instructions at the lowest possible level. It's the digital equivalent of "look, but don't touch." Using a hardware write blocker guarantees that not a single bit will be changed on the hard drive regardless of what the operating system tries to do or what the user accidentally does.
Using a hardware write blocker — and using it properly, which is key if the write blocker being used has an on/off write-protect switch — will prevent all of the above data destruction scenarios, forcing the hard drive to be truly mounted as read-only, with no chance of accidental or unintentional data manipulation on the drive. The operating system might complain with a few error messages about not being able to write to the drive, but those error messages are the good kind of error messages, providing assurance that the write blocker is working and doing its job of blocking all writes.
Software-based write blocking methods exist, but the software methods are not as simple, repeatable and idiot-proof as the hardware solution. Hardware write blockers are routinely used during forensic analysis on hard drives for criminal investigations. Before digital evidence can be presented in a court of law, it must be handled in a forensically-sound manner that precludes evidence tampering. Using a hardware write blocker while analyzing a hard drive keeps the evidence intact in its original state at the time of acquisition and virtually eliminates any chance of user error.
Affordable hardware write blockers that operate with SATA/IDE drives can be purchased new for around $50 and work well with external drives that can easily be removed from their FireWire or USB enclosures. Some of these write blockers may include an on/off write-protect switch that could be accidentally disengaged, but a simple "poka-yoke" solution is to just superglue the switch in the write-protect state.
Hardware write blockers that work in-line with FireWire/USB connections and USB thumb drives (Thunderbolt write blockers are on the horizon) retail in the range of $200-$600. For the brave, an open-source project called FIREBrick provides the firmware and instructions for building a DIY FireWire write blocker using about $200 worth of parts. The bottom line is that it's economically feasible and advisable to provide best-in-class protection against inadvertent loss of client data due to operating system (mis)behavior, virus activity or user error.
At the end of the session, if newly modified large files need to be returned to the client, consider burning to optical media or copying to a secondary "write-safe" hard drive. Forego the write blocker and write back to the client's drive only if the risks outlined above are understood and noted by the client.
