sync with external folder option gets unchecked

Scrivener Scrivener for macOS
1

Good evening everyone.

The option «Check external folder on project open and automatically sync on close» keeps gettings unchecked.

I have no idea why, but I always have to check it again.

Projects are synced with Dropbox, maybe that gets into the way I don’t know.

Thank you.

2

Section 14.3 in the Manual (Scriv 3.1.5) is a good source for the Synchronized Folders feature. I haven’t used the feature in quite some time so my knowledge-store about it is limited. I’m wondering if this Tip (in a yellow box) at the very end of 14.3.2 is a clue for you*:

If that (or something else in 14.3) doesn’t clear things up for you, reply with a full description of the steps you take, software, hardware, etc. Someone might have a ready answer.

*I’m assuming that you realize this feature is not a mechanism for syncing projects with iOS, for example.

3

“Sync with external folder” is NOT a way to keep two copies of the same project synced (I learned this the hard way by having my project corrupted several years ago. Don’t be “new and foolish” me. :frowning: )

If you want to keep two Macs synced, the way to do it is

  1. have Dropbox installed on both machines,
  2. Close your project in Scrivener on both machines, and
  3. in Finder, move your project to a folder inside the Dropbox folder on one machine.

Always wait for Dropbox to finish its sync before you close your laptop or let Machine A sleep. Always wait for Dropbox to finish syncing before you open your project on Machine B. Always open the Dropbox copy when you start to work on the project, and close it when you leave Machine A to work on Machine B. (If you have trouble remembering to do this, like me :smiley: , you can turn on Automatic Quit {Scrivener->Preferences->Automatic Quit) } with an interval long enough to be not annoying but short enough that Scrivener actually quits on the one machine before you start up with the other.)

A word regarding backups: Don’t think that because your project is on Dropbox, that it’s backed up. (I made this mistake, too… :blush:) A mistake can propagate from Mac A to Dropbox to Mac B like lightning. Because of Scrivener’s complex project structure, restoring from Dropbox’s internal automatic backups is nearly impossible. I suggest that

  1. You use a separate cloud service, like Google Drive, for your Scrivener-managed automatic backups (Scrivener->Preferences->Backup). Have the same location set for BOTH your machines.
  2. You have the number of saved backups set to 25. (Yes, I had my number of backups set to a mere 5 at one time. Before I realised that I had a corrupted project I had tried more than five fixes, so all my five backups were corrupted. Again, don’t be “new and foolish” me!)
  3. you have “Use date in backup file name” set to ON (this prevents much confusion.)
  4. You have “Compress automatic backups as zip files” set to ON (essential to avoid corruption on Google Drive!)

Hope all this helps!

4

Thank you both.

As a matter of fact, I am syncing projects via Dropbox and not via the syncing to external folder.

The syncing is for editing my works onto my Android peripherals, like I did just this morning, when I created a new text chunk creating a new file into dropbox - still I have to open Scrivener to sync.

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.

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.

I’ll made some tries.

Thank you.

5

The problem is that you let several Macs write to the same sync folder. Don’t.

6

Thank you.

I see what you mean but I wonder:
a) how could I ever work with the external folder keeping three or four of them - that could really leads to conflicts, and
b) how could I change the sync folder for every different Mac, since the folder path is stored at project level and synced amongst all the Macs via Dropbox…

I may be missing something, I guess.

Thank you and have a nice evening.

7

The safest way to use an external folder and share your project between multiple Macs is to decide that one of the Macs is “canonical.” That is, sync the external folder exclusively from that Mac, making sure that it has all of the most current changes first.

Attempting to keep a single external folder current from several different Macs will not work, and is fairly likely to cause data corruption problems.

Katherine

8

Thank you. I get your point but let me spell it out a bit

Say a have A, B and C Macs. I decide A to be the main, or canonical, the only one to sync with external folder.

I have project Z which is synced across all Macs with Dropbox.

I edit Z with A Mac, close the project, it gets synced both via Dropbox and to external folder.

I get out, get hit by inspiration, open my Android phone and work on the external synced folder, creating a new file or, worse, editing an existing one.

I get to work where I have B Mac. I cannot work on project Z, for if I did I would cause conflict when, later on, I would open project Z on A Mac at home. As a matter of fact, I could work on the same text chunk I edited on the road on the Android phone, which got synced back to Dropbox but not as yet back into project Z via A Mac.

I could leave A Mac running as a server, BUT you cannot leave a project open in different instances of Scrivener or you get conflicts, so whenever I am finished working on any of my Mac I have to close the project and wait Dropbox syncing before shutting down the Mac.

That scenario sort of frustrates the whole sync to external folder thing. Maybe you can use it only if you work on a single Mac and one, or more, Android (or else), devices then.

Or maybe you should thing about configuring a Mac as main and put some sort of automation you can launch remotely to a) open the project Z on that Mac b) sync with the external folder c) close the project. You launch that only when you are sure project Z is closed on all other Macs.

Thank you.

9

The sync conflict would only happen if you changed the same document(s) both within your project with Mac B or C and with your Android device. The Android device can’t easily cause binder conflicts (IMO the nastiest to correct) because, other than adding a new document or deleting a document completely (deleting documents on any machine save Mac A being a Bad Idea in the case you postulate), nothing external folder sync does affects the Binder. So you are left with isolated document conflicts.

Now, if you’re being careful about always letting Dropbox sync before opening your project, you know that all your Mac changes are in the project before you open it on Mac A. If you turn on “Take snapshots of affected documents before updating” in the Sync with External Folder dialog, you will preserve changes made with Mac B and/or Mac C in a snapshot for each Android-edited document when your Android edits are added.

People are scared of sync conflicts (rightly!) but in the case of single document conflicts, Scrivener is very good about preserving all states of the affected documents, by making copies in an automatically generated Conflicts folder. So if Scrivener reports a conflict, what you do is:

  • Check the copy of the affected doc in the Binder. Is it the Android version? If so, look at your snapshot, run a comparison, and copy appropriate changes from the snapshot back into the main document. Otherwise,
  • Look at the copy of the document in the Conflicts folder. It should be the Android changes. Select All and Copy the entire text, then return to the Binder copy and Select All and Paste to put your Android changes into the Binder copy. Then follow the process above to resolve your conflicts.
  • Finally, put the docs from the Conflicts folder into the Trash, and delete them from the Trash, since the changes are incorporated and having extra copies around can be confusing, at least for me. :smiley:

I know it sounds like a lot, but if you avoid editing the same docs both on Android and on subsidiary Macs it should happen seldom. Beside, it’s more complicated to describe than to do. :wink:

10

All software has limitations, and you have to accept and adapt your work-style to those limitations.
If you want to get rid of the limitations of “sync with external folder”, replace your Android device with an iPad or iPhone and buy iOS Scrivener. That would solve your problem. :wink:

11

Yeah, I had the same thought.

@tsolignani: Basically, you’ve reached the limit of what Scriv is currently able to support, for your non-supported Android platform. :slight_smile: But there is some good advice above, particularly Silverdragon’s discussion of how to live with and navigate sync conflicts. (“Embrace your inner conflicts!”) I’m sure you’ll find a reasonable workflow, until such a time as DroidScriv is released. 8)

Best,
Jim

12

Addendum to sync conflicts process: It would be unlikely, but it wouldn’t hurt to check your snapshot and make a new one if needed before you copy and paste as in step 2 above. Snapshots hang around until you actively delete them, so it’s not as if you’d be writing over anything.

Hope this helps!

13

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.

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.

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. :slight_smile: 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.

14

Thank you. That was a really deep explanation and now all my doubts are gone.

I’ll keep my set up with projects and external folders syncing via Dropbox, I’ll just fix symlinks to avoid sync on close and open option disabling.

I am not yet dumb enough to use iOS, maybe when I’ll grow older… :wink:

Thank you and have a nice weekend.