When Two Macs Edit the Same File

Two people, two Macs, one shared folder. She edits the pricing sheet on the plane with the Wi-Fi off. He edits the same pricing sheet at the office an hour later. Both of them save. Both of them are right.

This is a sync conflict, and it is not a bug. It is the only honest outcome when two versions of a file have both changed since they last agreed. What separates a good sync tool from a bad one is not whether conflicts happen. It is what the tool does in the five seconds after it notices.

Why conflicts happen at all

Syncing is a comparison, not a stream. A sync tool wakes up, looks at the file on your Mac, looks at the file in the cloud, and asks a simple question: has either one changed since the last time I saw them agree?

Three answers are easy. If neither changed, do nothing. If only the local copy changed, upload it. If only the cloud copy changed, download it. The fourth answer is the hard one: both changed. There is no comparison that tells you which set of edits matters more, because that is a question about your work, not about your files. A timestamp cannot answer it. The file that was saved most recently is not the file that took more thought.

Offline work makes this common rather than rare. The whole point of taking a folder offline is to keep editing while the network is gone, which means the gap between "last agreed" and "now" can be hours long. Anything can happen in that gap, including someone else opening the same file.

Keeping both versions is the right default

When sync finds edits on both sides, it has exactly three options. It can overwrite the cloud with your copy, overwrite your copy with the cloud, or keep both and let a human sort it out.

The first two are the same mistake in different directions. Both destroy work that somebody did on purpose, and both do it silently, which is the part that actually hurts. A file that quietly reverts does not announce itself. You find out days later when you go looking for a paragraph you know you wrote and it is not there, and by then there is nothing to recover from and no record of what happened.

Keeping both versions is worse in exactly one way: it leaves you a small mess. You end up with two files where you wanted one, and you have to open them and decide. That is a real cost, and it is a cost you can see and pay in two minutes. Silent data loss is a cost you cannot see and may never be able to pay. That asymmetry is the entire argument, and it is why Orbit keeps both versions when offline edits collide with cloud edits rather than picking a winner for you.

The rule underneath this generalizes past sync: when software cannot tell which of two human intentions is correct, it should preserve both and interrupt, not guess quietly. Guessing is only acceptable when being wrong is cheap. Losing someone's afternoon is not cheap.

Deletions deserve a pause, not a propagation

Deletion is the case where automatic sync gets genuinely dangerous, because a deletion looks identical whether it was deliberate or accidental.

Picture the folder that is missing forty files. Maybe someone cleaned up finished work on purpose. Maybe a drag went sideways and dropped a subfolder somewhere else. Maybe a disk did something strange, or an app cleared a cache it manages, or a file browser collapsed a folder and a selection got much wider than it looked. To the sync engine these are the same event: files that used to be there are not there now.

A tool that propagates that immediately turns a local accident into a permanent one, because it removes the copy you would have restored from. This is the classic way people lose files to sync software, and it is worth being blunt: the cloud copy stops being a safety net the instant it mirrors your mistakes without asking.

The safer behavior is to stop and ask. In Orbit, deletions pause syncing for review instead of flowing through. That is deliberately a little annoying. A pause costs you one decision. Propagating a bad delete costs you the files and the backup at the same moment.

Two related habits are worth building regardless of tooling. Keep a separate backup of anything that matters, because sync is not backup and never has been. And if you only need a folder to come with you, use download-only mode rather than two-way syncing, so local changes stay local and nothing you do offline can reach the cloud copy.

Set folders up so conflicts stay rare

Most conflicts are structural. They come from two people having legitimate reasons to be in the same file at the same time, which is usually a sign that the folder layout is asking for trouble. A few arrangements help.

• Divide by person or by stage, not by project alone. A folder that both people write to all day is a conflict generator. Separate working folders that feed one shared delivery folder are not.
• Take the smallest folder you actually need offline. Every offline folder is a window during which edits can diverge. Selecting a whole project when you only need one directory widens the window for no benefit.
• Treat the offline period as checked out. If you are taking a folder on a flight, say so. This is a social protocol, not a technical one, and small teams run on social protocols anyway.
• Sync before you disconnect and right after you land. Orbit checks the active connection every couple of minutes while it is running and again when the network comes back, and you can also trigger a sync yourself. The shorter the divergence window, the fewer collisions.
• Do not put live databases or app-managed libraries in a synced folder. Anything that writes constantly and keeps internal indexes will generate conflicts on files you never touched by hand, and the halves will not merge cleanly.

What no sync tool will do for you

Be clear about the ceiling here. Keeping both versions is a safety behavior, not a merge. Nothing combines two people's edits to a spreadsheet into one correct spreadsheet. Orbit does not do live co-editing, and it does not lock a file on one Mac while another Mac has it open. If your team genuinely needs several people typing in one document at the same moment, you want a document tool built for that, and you should use one for those specific files while keeping the heavy project folders on a drive.

What a sync tool owes you is narrower and more important: never lose an edit quietly, never let a deletion travel without a human saying yes, and make the moment of disagreement visible while you can still do something about it.

The takeaway

Judge sync software by its behavior on the bad day, not the good one. On the good day everything looks identical. On the bad day, one tool hands you two files and a decision, and another hands you a folder that is quietly missing an afternoon of work.

If your team is sharing folders across machines and nobody can say what happens when two people edit the same file, that question has an answer already. You just have not found it yet, and the way people usually find it is expensive. If you want to talk through how to lay out shared folders so it comes up less, get in touch.