Beta 13 -- "Files Recovered" loading exception on support files for non-RTF docs

Hi – Beta 13 throws a warning when it encounters unexpected files in the data folder for a user’s project, and it adds those files to the binder in a dated “Recovered Files” folder.
But Scrivener supports virtually any file type within the project, enabling any doc in the binder to be opened in the preferred editor for its type. Some of these docs have supporting files that users will want to keep right where they are. For example: HTML is a file type viewable directly within Scrivener. The user may have image files associated with an HTML doc in the same folder as the HTML, or in a subfolder. These files aren’t strays and should not generate “Files Recovered” errors or be added explicitly to the binder.

There’s no certainty that a doc type that a user elects to manage within a Scrivener project will be complete in a single file. And I suspect that L&L will be dealing with a raft of user support requests if Scrivener is overly strict in enumerating those appurtenant files.

Thanks for taking a look!

Rgds - Jerome

I think my first question is, why is this being done? It sounds inane. Are those files causing Scrivener to fail compile? To fail to display? To fail to work?

Hi Jerome, this message means that Scrivener has found files which are not part of your Binder at the moment. They most likely have been some time ago, but due to some user actions, syncing, incomplete copy paste or whatever unexpected reason, are within the project Files/Data subfolder but are not visible and added to your Binder. Scrivener will check for any file which is not part of the Binder and add it for you to the Recovered Files folder, or you will never see these files in your project, and the files will lay behind dormant in your project folder structure. This is like an automatic recovery of files which are left behind in your project folder structure. If you are sure that these files have been part of your project before opening the project, please send us an archived version of your project before you get this message. This will help us reproduce the problem in case of a bug in the automatic file recovery procedure.

The error message itself suggests that Scriv’s project loader is scouring the Data folder for remains of an incomplete or unsuccessful synch. Users will not tolerate lost work, and need assurance that unaccounted files that seem to belong in the binder are identified and recovered on loading. But I think Scrivener will have to allow for exceptions at the document or doc type level, for the wide variety of reference materials the program enables users to manage within a project.

Tiho, thanks, For my own part I can easily work around these messages. Other users’ results will depend on the range of doc types they manage within their Scrivener project, and whether their docs are complete as solo files.

Cheers – Jerome

This happened to me and the only recovered file is “content.checksum”

Any idea what this is and is it OK to simply delete it? (everything in the project looks fine otherwise).


Hey Jerome, I couldn’t figure it out from your OP or the resulting discussion, so was this message generated by files that you moved into the Scrivener project folder? In other words, you didn’t import it using Scrivener, you bypassed Scrivener and put it in the project folder yourself?

Just curious…

content.checksum should not be recovered as it is part of the project. Does it happen every time with every project, or accidentally with one project.

Well there was one that I dragged there, a CSS file that serves as a stylesheet for all the HTML files within my project. But there were others. Scriv allows us to manage XLSs, PDFs, HTMLs, all sorts of formats as binder docs. If I edit these and they lay down supporting files in their folders, I don’t believe I’m bypassing Scrivener. Scriv is a whole-project development environment for writers and I’m using it as intended.

Rgds - Jerome

Agreed. You wouldn’t think Scrivener would generate a warning if the docs are still in the binder.

content.styles was “recovered,” and I’m pretty sure Scrivener generates that.

I don’t know which directory it came from, either, just somewhere in the project (hundreds of places it could have been).

Contents of the file: DCE8AC13-C669-4282-83CD-C750A90B0103

This corresponds to this style entry in styles.xml.

<Style ID="DCE8AC13-C669-4282-83CD-C750A90B0103" Name="1cm" Next="DCE8AC13-C669-4282-83CD-C750A90B0103" Shortcut="1" Type="Para+Char" FontChange="Face+Size"> <Format><![CDATA[{\rtf1\ansi\ansicpg1252\uc1\deff0 {\fonttbl{\f0\fnil\fcharset0\fprq2 SegoeUI;}{\f1\fnil\fcharset0\fprq2 DejaVuSerif;}} {\colortbl;\red0\green0\blue0;\red255\green255\blue255;} \paperw12240\paperh15840\margl1800\margr1800\margt1440\margb1440\fet2\ftnbj\aenddoc \pgnrestart\pgnstarts0 \pard\plain \fi567\sa120\ltrch\loch {\f1\fs28\b0 Attributes}}]]></Format> </Style>
Is Scrivener now going to lose that style from the document, that I carefully placed there?

content.styles must not be in a document subfolder. It has absolutely no impact on the project when you place files all over the project, if Scrivener is not accessing the file from the right location. Only that file from the proper location will be used and not the one you wish for. Styles are general per project and not per document, and Scrivener does not write content.styles in each document subfolder. This style entry and file you have placed carefully, are not lost. They have never been used.

It only happened the first time after I updated to B13. I just searched in Windows Explorer and there’s only one file with this name, so it wasn’t an accidental duplication.

I’d request not only an exception pattern, enabling Scrivener to ignore selected files in the Data folder and subfolders, but also that Scrivener defer the warning message until after the project has been loaded.

Thanks for considering – Jerome

I’m getting this issue since installing the v13 beta.

it found 30ish files and put them in the RECOVERED folder.
they are all STYLE files,

Please add a way to disable this.

I wrote a script that tracks wordcounts per file and puts them in a .log file next to the .rtf file. It’s worked fine for years with scrivener.

I love scrivener 3 but changing to uuids from simple numbers and now this makes it feel like I’m losing control over the program.

I understand why you’d have it have automatic behaviors for the average user, but please add a way to opt out.

Then why did that particular style in that particular document revert?

And I’m pretty sure I didn’t deliberately put it there. I noticed it once, opened it, saw its contents, looked for why, and found styles.xml. But Scrivener put it there, I’m pretty sure.

I don’t like this “feature” either.

@rwfranz: Can you please upload(or send via email to tiho at a small demo project which includes “content.styles” files and have been recovered unexpectedly? In my tests the “content.styles” files are properly left next to the “content.rtf” file and not moved into the “Recovered Files” folder.

@shaun: Using UUIDs is needed to make mobile syncing possible and allow users editing the same project from multiple devices. This functionality cannot be achieved using regular increasing numbers, as we used to do in v1.9.