Automatically recover files inside project folder

I’m hoping someone can explain what this actually means, from the Scrivener Manual, p 636, section B.2.1.

Automatically recover fi les inside project folder Of particular use to those
working across diff erent machines, using synchronisation or cloud tech-
nology, this option recovers “confl ict” fi les that may be generated by those
tools, if items within the project are accidentally edited in two locations
before syncing. Disabling this feature should only be done if you do not
use these tools. When disabled, fi les you places into the project folder’s in-
ternal hierarchy yourself will not be recovered. Note that it is not advised
that you do this under any circumstances.

It is not clear what “recovered” refers to, as in, “recovered” from what exactly. There seem to be multiple senses of what recover might mean, or what one is recovering the files from: an accident, a bug, an action taken by mistake, an intentional action you’ve changed your mind about…? An explanation that didn’t use the word “recover” and that unfolded what was taking place would probably help.

I am using sync folders, but all on the same machine, and without any cloud involvement.

Of particular interest is how what is being described (and warned about) here might relate to matters discussed in this thread, as it seems the behavior described there could qualify as a “recovery” of files “generated by” the sync tool.
External Folder Sync brings back files if deleted from Trash before sync

Thank you!

I would have broken this into 2 or 3 paragraphs… but this is how I interpret this passage:

This is pretty clear. It’s sadly easy to work on a document in a project on iOS, forget to run Dropbox sync, and then start working on the Mac/PC version of the same document in the Mac/PC copy before you remember to run the iOS sync. What this does, is when you finally run your iOS sync and go back to your Mac/PC, Dropbox itself will generale “conflicted copy” versions of the offending file(s). What this option does is that it puts one copy in the Binder, and the other(s) in a “Recovered files” folder. You then have the wonderful fun of hand-reconciling the two (or more) different versions. (If this ever happens to you, for Pete’s sake put all but one copy in the Trash once you’re done and permanently delete them!) This should never be a problem with External Folder sync, but if it is, you should see a bright yellow folder named “Recovered Files.” But really, we’re talking iOS Dropbox sync, or maybe if you use some other cloud service to work on your project directly with Mac/PC Scrivener on different machines.

This is telling … (foolishly) brave folks that if they do something not recommended like adding a file directly into their project folder somewhere, it will be deleted without warning if this option is turned off. One way to do this would be to create a file directly in your project folder with an Android editor using something like Dropbox or OneDrive to directly access your project folder. Not cool.

In any event, not something that should affect External Folder Sync, ever.

1 Like

Thank you for that explanation! I’m familiar with “Conflicted” files from when I used Dropbox, and still occasionally get them with Google Drive. But never involving Scrivener, which I would not want to actually work on over a cloud network, where I’d spend too much time watching the sync status. That paranoia I can do without.

It was the reference to “synchronization” that made me wonder what was what. “Automatically recover files inside project folder” seemed like it might have something to do with how Scrivener processes new files in the sync folders, which I use extensively extensively and just had a problem with. I’ve never seen a bright yellow folder named “Recovered Files.” But I have seen files from the Sync folder’s “Trashed Files” subfolder returned to the binder. That then creates or sets up potential conflicts, but as you seem to be confirming, “This should never be a problem with External Folder sync,”

It was that problem I was having with sync that somehow led me to question that option.

It’s almost as though Scrivener is finding previously deleted files in the sync folder, reads them as “new items in the sync folder,” and is “recovering” them to the binder, but is skipping the Big Yellow Folder and just placing them at the bottom of the Reference (?) folder.

That setting has always been turned on for me - I never noticed it until today. But I’ve noticed something just like what you describe happening in my sync folders.

I will run sync. Then open “Filename [123].rtf” in Word, where I will edit, save and eventually close the file.
This leaves behind an automatic Word backup named “Backup of Filename [123].wbk” along with the original.

If I don’t manually delete that backup file, which Scrivener knows nothing of, it will be deleted next time I run sync. It doesn’t go to the Recycle bin. At first I was scrupulous about deleting it, but I’ll sometimes leave it to Scrivener. Nothing extraneous should ever be in these folders.

If I do not close the rtf in Word before trying to run sync, no one is happy. In that case, Scrivener will encounter not only the Backup file, but also a temporary file named “~$Filename [123].rtf” that Word uses to lock the file or for some other housekeeping purpose. Because this file has an rtf extension, and also has the same binder position number appended to its name, when Scrivener syncs it encounters weirdness, and it reports that sync ran, but with errors, and what you end up with in the binder can be… strange.

Back to that “Automatically recover files inside project folder” setting… now I’m not so sure… does it really have nothing to do with what happens with external folders (which, for the record, is not at all the same as the “project folder”)? It does seem to have something to do with what happens with the sync folder. Or is that a problem of terminology?

1 Like

Yes, it really has nothing to do with External Folder Sync (EFS for short), and I think it’s a problem of terminology. When the L&L folks use the term “project folder” they mean the folder that has the name “XXXXX.scriv”. When they talk about “sync” without qualification, they are usually referring to automated cloud sync (either with iOS or just generally with cloud-resident projects), not EFS.

Yes, this is EFS doing what it’s supposed to do. (Correct me if I’m wrong, L&L folks!) Again, it has nothing to do with the Options setting. If you have the EFS file type set to “.rtf”, nothing except “.rtf” files will be synced back to Scrivener, and extraneous stuff will be moved to the Trashed Files folder.

I imagine so. Two files with a “.rtf” extension, and the same Binder ID number cause the EFS routines on Mac deep confusion; I get a polite error message saying, essentially, “Please stop sync and figure out what you want. If you don’t stop, you get what you get…” only wordier and about 2 paragraphs long.

If a new “.rtf” file without a Binder ID appears inside either the Draft or the Notes folder (inside your EFS sync folder) putting it inside your Draft folder or your Research folder (at the bottom) respectively, is what EFS is supposed to do. EFS assumes that you’ve added a new document on purpose, and it’s up to you to slot it into your notes or your Draft folder, as appropriate. That includes any files that don’t have the Binder ID just before the extension, as just before the extension is the only place EFS looks for the Binder ID. …

The fact is that EFS is not very sophisticated. Once again, this options checkbox almost certainly has nothing to do with it. But EFS runs entirely on filenames in that external folder. If for some reason known only to Microsoft, duplicate files are getting created by the OS or by Word, with extra text after the Binder ID, I’d expect EFS to do exactly what you report, just copy them into the project and stuff them either at the bottom of the Draft folder or at the bottom of the Research folder, as appropriate.

Of course as you already know, extra text before the Binder ID would be worse. Much worse. At least with the duplicates you’re seeing, you stand a chance of just nuking them…

1 Like

Yes. Files in the External Folder that already have a Binder ID have a known location inside the project. Scrivener assumes that, no matter how dramatically changed the file might be, you want it to go in that location.

Without a Binder ID, or with a duplicate ID, Scrivener doesn’t have clear instructions. It’s not going to throw the file away – The Human put it in the folder, so they must want it! – but it doesn’t know where to put it.

1 Like

On the contrary, EFS knows exactly what to do with no binder id—it puts it at the bottom of the Draft folder if it finds the file in the external Draft folder, or at the bottom of the designated notes folder if found in the external Notes folder. It’s just not very sophisticated about what constitutes “no Binder ID”. But duplicate IDs—that confuses it mightily.

1 Like

Other than a test or two early on, I have so far stayed clear of adding files to the sync folders as a way of adding them to the binder. I’ve stuck only to editing rtfs created by S.

When I want to add a doc that originated in Word (which is where nearly all of it originates), I create a new binder doc with its name, then I sync it, open the rtf in Word, and straight copy and paste from the source Word doc. Then I sync it back up to Scrivener. This preserves not just the formatting, but also the the applied Heading Styles more reliably than file import, while “import with split” inexplicably loses the Heading associations altogether (and is one of my real disappointments with Scrivener 3, tbh), though the text formatting is retained.

1 Like

Makes sense. No hunting for files at the bottom of folders—you start with the new file already positioned, and with the metadata you prefer already in place. It’s largely how I work myself (although I use Markdown and a code editor rather than Word), but I set up a folder called “Inbox” to receive any new documents from the external Notes folder. That way anything new I write is isolated, and since I put the Inbox at the top of my binder, I see anything new that arrives.

1 Like