It’s completely counterintuitive that trying to store important documents in two separate cloud stores should put you at risk of losing them altogether. But that is the essence of the conflict which has arisen between Dropbox and macOS Sierra’s iCloud features. To understand how this has happened, we need to go back to the fundamental ideas behind copying and moving files.

The simple (Mac) computer model, before remote storage, sharing, and the like became available, centred on two simple actions: copy, and move. When you dragged a document from one folder to another, all you had to know was whether the two folders were on the same volume. If they were, then the document was moved; if there were on separate volumes, then the document was copied so that you ended up with one copy of the document in the original folder, and one in the destination.

This was so because of the way that computer file systems work: if the two folders are on the same volume, the document’s data aren’t actually moved at all, what happens is the file system records that it is no longer in the original folder, but in the destination instead. As directory and other file system structures do not span volumes, the whole content has to be copied across to a destination volume, making a second copy.

That simple model started to break down when aliases and links arrived. Because these are not actual copies of the document, but pointers to where it is, decisions had to be made as to whether to move or copy the original document, or just the alias/link. As I have explained here, the answer is not so simple, and at times can get quite confusing.

Most of the time, most of us do not go round moving or copying aliases, and in any case, so long as we distinguish the original document from its links and aliases, we are not likely to come a cropper and lose anything important.

Offsite storage, the cloud in particular, ups the stakes and becomes significantly more risky. So long as cloud storage is treated as just a different volume, I think most of us are comfortable in coping with it. If I have an important document here, which I wish to put straight into offsite backup, all I have to do is drag the document from my working volume to the cloud store, and it is copied across. I then have one copy here, on my Mac, and one in the cloud. If my Mac gets stolen, consumed by fire, or the internal storage dies, I can access the copy from the cloud.

Sadly, those simple rules were readily discarded. Instead of cloud stores behaving like separate volumes, the industry (not just Apple) want us to feel that the cloud is actually part of our computers and devices. So in El Capitan, when you drag a document to your iCloud Drive, it is by default not copied there, but moved. No problem, you then learn that when dealing with cloud stores, you now have to tell them that you want to copy and not move, here by holding the Option key down while dragging the document into the cloud folder.

The next step takes this a little further: instead of leaving it to the user to decide when to copy/move documents to the cloud, the operating system decides when to. The purpose in doing this is to help users manage their storage, so that they can free up space on their startup volume. As many of us struggle to keep on top of that problem, it will really help users out. And that’s exactly what macOS Sierra does in its new storage management features, particularly when you Optimise Mac Storage and Store in iCloud.

The first of these is an option in the iCloud pane which, by default, is turned on, so you don’t have to worry about it. Indeed, unless you go poking around in the iCloud pane in Sierra, you may never realise that it’s there, let alone activated.

The second, accessed via a button hidden in the Storage tab of About This Mac, is phrased differently, but includes the same basic process operating on files on your Desktop and in your Documents folder.

What these enable is a process in Sierra to keep watch on the free space on your startup volume. When that becomes low, it will start moving across older files from your Mac to your iCloud storage. In doing so, it leaves behind its equivalent of an alias, with the extension .icloud, which points to the content stored on iCloud. You can of course turn this off, and Sierra does notify you when files are being moved into the cloud, but you don’t have any particular control otherwise.

All you need now is another cloud or similar service which is relying on those same local documents, and there’s a recipe for disaster. Optimise Mac Storage moves the documents to the cloud, leaving stubs behind. The other cloud storage software notices that the original documents have been removed, so removes them from its copy of your files, and stores the .icloud stubs in place, which are worthless. Instead of safeguarding your documents, that second service ends up storing empty stubs to your vital content. When the phase of the moon is wrong, the primary cloud storage will have a hissy fit, and all you will be left with are those useless stub files.

The original copy/move model has become so complex and opaque that users are losing any sense of where each document really is. In such circumstances, they become completely reliant of the software to handle that for them. For the software, it is essential to be able to tell apart real documents with real content, aliases/links, and iCloud stubs. And that is where Dropbox is running into problems, and other software will too, particularly if it does not recognise what .icloud files are.

The plain moral for users is that you must keep different cloud systems fundamentally separate. By all means use these new features, but segregate them carefully. Don’t leave two cloud systems trying to handle common files, as they will trip over them sooner or later. If you can, use just a single service – iCloud, Dropbox, or whatever – on each computer, and that way you won’t be caught by the left hand moving files into the cloud, and the right hand trying to back them up to a second cloud service. That would be a good way of risking data loss, despite the best of intentions.

The longer-term answer requires developers to recognise these issues and cope better with them. There is no excuse for mistaking a .icloud stub for a local file, so you mustn’t treat it as one. This is going to require fixes in most tools which work largely with files: sync utilities, backup tools, and the like.

I also think that cloud vendors need to look again at the human interface. There’s a difference between illusions like the Desktop and deceptions that are being used in cloud syncing at the moment. The user needs to be clear what is going on, so that they don’t inadvertently stumble into disaster.