I’m running into the same problem I had earlier in the Beta3 test with one of my projects converted projects where everytime I open it it reports that it has detected files I need to resynch. Before I create a new project and drag and drop all the documents and folders across from the old project (which fixed the problem last time) I’m hoping someone can tell me if there’s a way of finding out which files are causing the problems as its not listing them in the binder after the re-synch.
I’m interested in seeing what the problem is, or more likely, where.
What other program are you using to open the external folder? If the answer is “none”, there’s no good reason to sync to an external folder. Scrivener may notice another program has opened the folder, even if none of the documents were changed.
I don’t know why this is occuring, perhaps there are some v1.9 ‘artifacts’ in the external folder, so v3 continually thinks it needs to bring them in? Just a WAG.
An easier way to fix it then creating a new project would be to create a new external folder.
Make sure you have a zipped backup of your project, just in case.
Close your project & Scrivener.
Rename the current sync folder, say by appending OLD to it.
Create a new empty sync folder using the original folder name,
Launch Scrivener & open your project.
Scrivener will present the ‘changes found in external folder’ dialogue. Click OK. Click Sync.
Scrivener will sync the project. This will be a re-export of everything from the project into the folder.
Jim’s method allows you to instantly recover the text without having access to a copy of Scrivener, if that is necessary, without having to dig through your backed-up project structure. For some people, this is going to be a win.
Yup. It’s okay for people to use Scrivener (or any software) casually – that is, not get deeply embedded in all of its various features. If I were using keywords and annotations and all of the other kinda of metadata that Scrivener makes it possible to use and manage, the Synch with External Folder method of creating an easily recoverable “last known text” recovery checkpoint would be deeply unsatisfying – because of course it sacrifices all of that rich metadata and status information. If you need that, you need to restore Scrivener and recover from the project backups. (Note that I’m not calling the external folder export a backup, because it’s not – it tracks the status of your updated files.) It all comes down to what your use cases are and what your workflow looks like.
Come to think of it, that would be a really handy way to quickly copy a chunk of text from your WIP without having to fire up Scrivener and navigate to the chunk in question, since navigation can cause project updates.
With apologies to AndrewHarvey for hijacking this thread…
The main use case I see for the Sync with External Folder ‘backup’ idea is if Scrivener suddenly becomes unusable/non-functioning on your machine(s). In this scenario, zipped backups or any type of backup of the project folder become much less useful. Yes, your words are in there somewhere, but what a mess to figure out.
If this non-functioning Scrivener situation is a permanent one, then having your docs all nice and neat in an external folder would make porting to some other tool easier. So would having a recent compile of your work.
If this situation is a temporary one, then you could continue editing and working in your external folder docs until Scrivener is working again, then sync your work back into Scrivener. Easy peasey. Some of us experienced a version of this scenario not all that long ago during L&L’s licensing service fiasco. In fact, I think it was during that time when someone here raised this idea of using Sync with External Folder as a backup.
If one were so inclined, one could even make it a true backup by copying and zipping up the External Folder on a periodic basis. I can’t be bothered at this point, but I could see doing that.
I’m a fan of cheap insurance, and that’s how I view this. As always, YMMV.
I’ve recommended Sync with External Folder and/or File → Export → Files as a way for people to convince themselves that their work isn’t “trapped” in Scrivener. That’s sometimes all it takes for them to take a deep breath, relax – stop yelling at me! – and address whatever issue they might be having. These functions also create a readily-accessible archive that’s completely independent of any existing backups, synchronization issues, etc. Again, that can be extremely valuable if the person believes (accurately or not) that their work is in danger of being mangled by forces beyond their control.
Sure, backed-up ZIP backups are all you need, but only if you understand how they are created, how to determine which version is which, how to restore from them if needed …
I just learned about Sync with External Folder and am happy to know that feature is there.
From a project management pov, I see a distinction between a “Scrivener project” and the actual “content” of the project, the majority of that being the text.
On that basis, having an external folder consisting of individually named rtf files corresponding to binder items, with each filename prepended with its numerical binder position, is actually the ultimate “backup” of a project’s formatted content, even though it’s not a backup of the Scrivener “project” itself. Like a multi-file version of a single-file compile of the full project.
As a (im)practical matter, the external folder might never get used as a regular backup, since (as JimRac outlined above) the permanent or long term non-functioning of Scrivener is rare and unlikely.
I use a program called X1 to index and search local documents and gmail. I have it set to index my Scrivener projects. The search results show a list of files all named “content.rtf” each in its own folder with a long and (to me) useless filename. Using an external sync folder, I can just point X1 to it, and the results will be more meaningful.
From what I’ve seen of it so far, Sync with External Folder seems like an adjunct of Scrivener’s Export functions, but the Backup functions too, in addition to being a separate “Sync” feature in its own right. Indeed it’s the latter that I am most pleased with, as it makes it much easier to move between Scrivener and Word while making the most of the Binder. Very happy to have discovered it this very cool capability.
Thanks for the suggestions. I use synch with external folder as an additional ‘backup’ of the most recent files, and to allow me edit the rtf files on android. I should also say that I have 5 other projects that do not have this problem. 3 that were converted from 1.9 and 2 that were created in beta.
On this particular project I do not edit the files externally so there is nothing that should be triggering the re-synch but I still like to have the rtf files directly available.
I tested it via a variation on JimRac’s suggestion. This is what I did:
1 - Opened the project
2 - Was prompted to resync
3 - Changed the sync directory to a new empty directory
4 - Synched
5 - Closed the project
6 - Immediately open the project and I’m told that “Changes seem to have been made to files in that folder since the last sync. Would you like to sync now?” I hit cancel and then close project. Prior to backup it resyncs a number of files, but its flashing through so quickly I can’t see which files it is pretending to resynch (and yes I do say ‘pretending’ because when I check the directory there is no evidence that any file has been updated. The latest date of any file is 30 March 2021 (which I agree).
I know the problem is an artefact of when I upgraded the project from 1.9 using an earlier beta version (subsequent versions don’t cause this problem) but I would really like to find out what files are causing the problem.
Re: the timestamps of files in the external sync folder:
It appears that the sync process retains the modified times of the documents – as though it is doing a copy-and-rename operation on original “content.rtf” files from the project folders, and not simply outputting new files from the live project…? .
Did a reboot (thought I might go all in on this one)
Opened the project
Synched to a new folder
Closed the project
Opened the project and it ‘detected’ that synched files had been altered.
I’m starting to form the view that it isn’t a problem with a converted individual files but with the project, and its probably resynching all the files. As a result I’m not going to be able to track down the cause and have given up trying to track down whatever is happening.
For the record, the way to fix this particular problem is to create a project in Scrivener v3 and to drag all the binder’s contents from the old problematic project across to the new project and then when you resynch to a new/blank folder everything works as expected. (And just in case something went wrong with the drag and drop I’m keeping the ‘old’ project - sans synching))
Well, Feb 2022 and the problem persists on Scriv for Win 3.1.1.0; the project was created by import from the Scriv V1 and I have never used sync folders until ~last week at the suggestion of @Mad_Girl_Disease.
Fortunately I have some new observations: I suspect it’s not changes in the content of the sync folder that are driving a sync op, but perceived changes in the project and either the strange way WIndows handles modified and created dates independently or Scriv, to wit:
Scrivener was started at about 09:30 on 10/02/2021 (having been shut down and backup created on 09/02/2022 at 17:14)
The latest modified stamp in the sync folder Draft is 09/02/2022 17:03, but the latest created IS 10/02/2022 09:31, i.e. when Scriv started up.
4 files are affected in drafts like this, 3 in notes; none of the draft files are in fact open in the editors.
The updated documents list is empty. Scrivener as synced from the project, not to.
It’s as though Scrivener is “touching” some files (which, why?) before doing the sync check.
Interestingly, quitting and restarting scrivener without doing anything in the app causes a) sync (dialog is there with progress bar <0.5s) b) no backup and on restart c) no sync prompt.
Something to do with date change??
Update
PS there is a small number of files in the sync folder whose created date/time correspond to yesterday’s shutdown time; their modified times are considerably earlier than their created times (hours, not seconds)
Not sure I fully follow what you’re describing. But if you have the option to “Check external folder on project open and automatically sync on close,” you might want to uncheck it until you have things better under control, since every time you close Scrivener or run sync, you are changing what you are trying to observe.
The files that Scrivener puts into the sync folder retain the same “Date modified” stamp as appears in S’s inspector.
The “Date created” shown in the inspector is when the document first appeared in Scrivener; it does not change.
In Explorer (in your sync folder), “Date created” is something else entirely: it indicates when that instance of the actual file was placed in the folder, which occurred when the sync operation ran, and is irrelevant for most purposes.
NOTE: It is possible to have a file with a “modified” date that is older than the “created” date. For most practical purposes, the “Date created” is irrelevant. I don’t normally display that column in Explorer; it can only cause confusion.
If you need to know a file’s “created” date, it can be found by right clicking it and viewing its properties.
A file’s “created” date can easily be more recent that its “modified” date. E.g., copy a file that was modified yesterday; in explorer, the copied file will still show the modification date was yesterday, but it will also show that it was “created” at the time it was copied, which it was. “Modified” refers to the file’s content; “Created” refers to the actual “physical” instance of that copy of the file, which is normally of no importance. The “created” date is not a reliable indication of which “version” of the document is the most recent, especially if you’ve been copying files from one location to another, which is how Scrivener’s sync appears to work under the hood.
