Wow. When Apple's copywriting is that down-to-earth, you know that something is different.
In seriousness, between this fragility and the lack of nested folders in iCloud, I get the feeling that Apple's taken a leaf out of Windows 8's book on this one... by focusing on non-power users, they'll generate a lot of hate and bad press from their once-loyal power-user customers.
1) That support article was written in the Tiger, if not the Panther, time frame. It's been around since at least 2005.
2) Mucking with this folder's rather like mucking with a Courier mail store, or a MySQL data directory: If you're gonna screw with it, you'd better know what you're doing and how all the pieces work. Apple hasn't published those details, and likely never will, so don't touch it. They've placed it in a hidden directory for a reason.
3) iCloud was never targeted at power users. Maybe it'll evolve at some point, but I wouldn't bet on it. Power users can use Dropbox, like they probably already are. Apple's not doing anything to stop you, there.
I'm a non-iCloud user (well, sort of), and I can't fathom a scenario where I would ever be tempted to use it. However, it's completely understandable what happened here and the guy even states this repeatedly: it was entirely his fault. He corrupted his own data.
That said, the magnitude of problems resulting from this surprised me. What happens if an iCloud sync folders gets corrupted due to a technical problem one day? Isn't this fragility also kind of a nightmare for Apple's developers?
Yeah, I don't think he can reasonably declare this to be his own fault. He's doing that to avoid criticism, but realistically, there's no conceivable reason that moving the local endpoint of the sync on one machine should cause the other machines to try to move their local endpoint. I can't even fathom how you could code it to make this kind of disaster happen.
Most file references in Apple's frameworks track by both the target's path and inode, with the inode considered "more canonical". This is used in NSDocument apps where when you move a file with it still open, the app can tell where it went and continue working at the new path. Finder aliases (different from symlinks) also do this.
Nowhere did he mention disabling iCloud, moving the directory back into place, and re-enabling it.
That might seem like the first step in solving this problem, and I wouldn't doubt that he did it if not for the instant jump to "restoring my iPad didn't help. everything is miserably broken so I called Apple."
I was thinking the same thing - was there an attempt to restore things to the way they were? Using time machine to revert that one folder would have been interesting to try, considering it was hosed anyway.
I think if he'd made a symbolic link within his Dropbox folder to his iCloud folder, it would have worked as expected. At least, that's how the Linux client works.
Yes. That is, in fact, how Time Machine backs up so quickly. But I believe there are no userspace utilities to create them (and major POSIX assumptions break down, so you need to be careful if you do it in your everyday data).
Much to my surprise, rsync on osx (with the --link-dest arg, iirc) can create directory hardlinks. I was unable to figure out any other tool to delete them; I ended up having to rsync an empty directory on top.
Wow - talk about dodging a bullet. I just had a co-worker tell me to try something similar since I'm an avid Dropbox user. Although I don't use icloud, this story probably saved me quite a bit of frustration.
Wow. When Apple's copywriting is that down-to-earth, you know that something is different.
In seriousness, between this fragility and the lack of nested folders in iCloud, I get the feeling that Apple's taken a leaf out of Windows 8's book on this one... by focusing on non-power users, they'll generate a lot of hate and bad press from their once-loyal power-user customers.