# sync with external folder option gets unchecked

**URL:** <https://forum.literatureandlatte.com/t/sync-with-external-folder-option-gets-unchecked/50337>\
**Category:** Scrivener for macOS\
**Tags:** support\
**Created:** [June 9, 2020, 7:04pm UTC](https://forum.literatureandlatte.com/t/sync-with-external-folder-option-gets-unchecked/50337 "2020-06-09T19:04:15Z")\
**Posts on this page:** 1\
**Showing post:** 13

<div class="post-metadata">

**Author:** ![AmberV](https://forum.literatureandlatte.com/user_avatar/forum.literatureandlatte.com/amberv/32/13021_2.png) [@AmberV](https://forum.literatureandlatte.com/u/AmberV)\
**Post date:** [June 12, 2020, 2:05pm UTC](https://forum.literatureandlatte.com/t/sync-with-external-folder-option-gets-unchecked/50337/13 "2020-06-12T14:05:43Z")

</div>

> [@tsolignani](#):
>
> The sync does not get disabled at all, just the option to automatically run an opening and closing. I suspect, as you suggested, it could be related to the fact that Dropbox paths are different amongst my several machine, for in one of them the Dropbox root in into an external disk.

There are two programmed modifications to your settings that will happen:

- If you load a backed up copy of your project, you’ll find the Path value has been deleted. As you can imagine, loading an old backup with a live and current sync folder would be awful. So we take a hard line on that and make it very difficult to even attempt to do that.
- If a project is opened and the sync folder cannot be found, then it soft-disables itself with the checkbox, like you describe. This gives you an opportunity to fix the path (either in the software or outside of it) and try again.

Until you resolve the path issue it will happen every time you switch computers.

> [@](#):
>
> I am using symlinks to handle different paths and I have for example a link to the project folder which works on every machine, but the matter is that you have to select the path for syncing through the finder and I cannot put it manually, I guess that if I could put the path manually everything would work.

And yes, symlinks are often the best way to handle these problems. For a while I had a situation where one machine had a different user name than the other one. So everything on my system that depended upon hard paths would break (including sync folders) if I switched machines. So I created a symbolic link in the /Users folder pointing from the user name on the other machine, to the real user name. That way, all preferences and settings that were looking for /Users/othermachine/Etc would be routed through to the correct /Users/ThisMachine/Etc folder.

> [@lunk](#):
>
> The problem is that you let several Macs write to the same sync folder. Don’t.

You might be referring to something else—but I don’t see anything in the OP’s report that would suggest this advice.

The short answer: it is safe to use a sync folder with the project that uses that sync folder, no matter where the project is.

- There are multiple chunks of code in this feature designed specifically to allow for this to happen (we already covered one of them above). That you can force a reconnection to an existing sync folder was in fact added to the software by request, specifically so people could fix path issues when switching machines.
- The user manual itself, a tip box from which someone quoted earlier in this thread, gives general advice on how to handle the very scenario tsolignani is describing, and provides further advice on how to avoid it.
- It also has this to say:

“When working from multiple computers sharing the same sync folder, always make sure your project file is the most current. It is perfectly safe to use the same project to sync to a shared folder from multiple computers provided you are always using the most recent version of the project and are not trying to bend the feature to sync two different versions of the project…”

- I have provided extensive help to users in the past, helping them wire up symbolic link connections so that their accounts can all equally recognise the same external sync folder from the same project. I wouldn’t have done that if it were true to say it is a “problem” to let multiple Macs write to the same sync folder.

To go into greater detail, for anyone interested:

The problem isn’t several Macs using the same sync folder, the problem is several projects. That has always been the risk, but for someone to sync the same exact project to the same sync folder is, all by itself, the way the feature is designed to be used. 🙂 Whether that project and the sync folder are on this machine or that machine is 100% immaterial.

So with that understood, what one needs to be cautious of is making sure that what seems to be “the project” is in fact the project in a technical sense (as opposed to the non-technical definition that I don’t think anyone here is advocating: “they are both my novel, I’m just trying to update this one with the changes made over my vacation on laptop”). If one uses synchronisation tools to keep a project the same on multiple machines, then that is by nature of the techology, a byte for byte version of The Project. If sync habits are good, and the technology chosen to do so is reliable, then we can safely think of it as being the same project, and it can safely sync to its own external folder, just as all of those bits and bytes did ten minutes ago from a different hard drive.

There is nothing mysterious about this. We can think of a project’s sync manifest as being a sequence of instructions for the software to follow. If that sequence is the same on every computer, and the folder it is paired against was generated by that sequence, then all we’re really talking about here is following a checklist of procedures from different clipboards with a different pen. The equipment doesn’t matter.

I use two computers and three boot volumes, and with that I have a central “inbox” type system set up for several different projects, each using their own sync folder. This area is synced between all devices—I can file notes to myself no matter where I am, using nothing more sophisticated than a text editor and a ’net cafe. When I switch from one computer to another, I copy the latest version of the project to it, replacing the old version, and upon opening the project, the first thing that happens is it safely syncs with the external folder.

There is no risk because the project that last synced with this folder did so when closing (I use the checkbox to always sync on open/close), which is the same copy of the project that I’m using on the second machine.

Personally, I use archive files to sync, as it is a much less complicated and error-prone approach. I use sync technology, rather than a USB drive (Resilio peer-to-peer in this case), to get the files and sync folder from one place to another, but I also by tangent sync the original .scriv project. I could just open the synced .scriv project directly rather than deleting it and replacing it from an archive on the second machine. In theory I am only replacing the same exact bytes. I choose this slightly more complex, and potentially redundant, approach because, like I say, it is less error prone (I am including my own self in the equation, not just the technology). I am only depending upon the easy to verify correct syncing of one single date-stamped file.

The important point is: whether I unzip an identical copy of bytes into the folder or just open the bytes directly myself—either way it is the same project that last synced with the external folder.

The main warning sign I would be keep an eye out for is if your project ever opens in a state where it presents multiple binders to choose from (huge sync conflict red flag) or imports conflicted data files or recovered files into the binder. If that happens, bad things have somewhere happened between machines and you cannot be assured that these are the same project any longer. You will definitely want to clear up the conflicts and then regenerate the sync folder from scratch, potentially salvaging any edits from it, by hand.

But you know, at that point we’re talking sync errors, which are just as bad as copy errors from a hard drive, or corrupted backups, or any other transmission failure that would cause us to strongly suspect the data as no longer byte for byte the original.

---

_[View the full topic](https://forum.literatureandlatte.com/t/sync-with-external-folder-option-gets-unchecked/50337)._
