Go ahead and listen to that pizza order. And then just think about it for a second. The world became so much more secure. Really. Believe me. You do. Don’t you?
Aus dem Newsletter einer Fluggesellschaft:
Delivery-date: Thu, 08 Nov 2007 10:14:51 +0100
Received: from …
by … with ESMTP id …
for <…@…>; Thu, 8 Nov 2007 10:14:37 +0100 (CET)
Date: Thu, 8 Nov 2007 10:14:37 +0100 (CET)
Lösen Sie bis Sonntag, 4. November, Ihren persönlichen 10 EUR Flug-Gutschein ein.
Well, just a few days ago I learned about a massive data loss bug that seems to have existed in OS X for quite a while: when you’re moving files from/to a volume (such as a mounted SMB share, a USB stick or a hard disk drive) and this volume suddenly gets unresponsive for whatever reason, the files you were moving are gone. Lost. Forever.
I just experienced a short (lasting only a few milliseconds) power outage at my home. Short enough for me to barely notice it, long enough for my external hard disk to power down and—guess what—being ungracefully unmounted.
I’m still quite lucky that the files I lost will be recoverable (even if it takes some effort and time). But nevertheless: a file system operation called “move” should copy and delete (
cp && rm) with the word “and” representing a logical conjunction… So if copying fails (for whatever reason) it should definitely leave the original file in its place!
As Tom (who seems to have discovered that problem in the first place or at least made it public) wrote:
Apple, please FTFF […]
In contrast to my wish of Java 6 on the Mac: Java would be nice to have (perhaps in a few months, sometimes in Q1/2008). Losing data due to a buggy file system implementation is a serious problem which needs to be taken care of now!
Update (11/16/2007): The Mac OS X 10.5.1 update is said to fix this bug:
Addresses a potential data loss issue when moving files across partitions in the Finder.
I have verified the correct behaviour: moving a file now operates transactional: OS X copies the original file to the destination volume. When that volume is suddenly disconnected, a partial (corrupted) file remains on the destination volume but the fully intact original is still there. After being successfully copied (and only then!), the original file will be deleted.