RTF Reader failed loading document file

I’m using Windows 7, with Scrivener 1.6.1.0

I’ve been getting this error:

Could not load document ‘Paul’s threefold revelation’
RTF Reader failed loading document file:
‘K:/Active_Writing/allegiance/wvz.scriv/Files/Docs/27.rtf’
Error: Unmatched ‘{’ in Rich Text file

There’s some additional text in the error box that describes how to deal with the problem. I’ve gone through the steps, and not only restarted Windows and Scrivener but tried opening files on a different machine (including a different copy of the project, a backup).

I get this error for different .rtf files in the project. The first one it had the error on contains about 40,000 words. But the other files with errors are not that long (maybe 300 or 500 words).

The good news is that I had a backup and it had a clean copy of the file. And I hadn’t changed anything in that particular file since the backup. HUGE relief (that was 40,000 words of my NaNoWriMo attempt potentially corrupted, three days before the writing marathon ends)!

It doesn’t seem to happen every time. But I’m sure you’re familiar with hearing from writers the bone-chilling, heart-gripping sensation of doom that overcomes us when software threatens the loss of our work. I need to know that Scrivener is going to be reliable.

Is anyone familiar with this error and/or have any suggestions? Could it be that Scrivener can’t handle really long RTF files? Or…? Should I re-install Scrivener?

Is there a way to scan all the files in my project to ensure none of them are currently corrupted, or does Scrivener do that automatically every time it opens?

Thanks in advance…

There are two possible causes of the problem:

One, the RTF file in question is corrupt (e.g. from a system crash) or incorrectly encoded, and Scrivener’s RTF inspector is detecting that and consequently throwing the error rather than loading the file, to prevent further harm to the file or to the project–loading it when it is corrupt could cause the program to not be stable, so you might end up with a crash later in the session, or the file might not load properly and if you in a panic edit it, you could overwrite a recoverable copy of the file unintentionally.

Two, the RTF inspector is not working correctly and is finding errors where there are none; this might happen if there were problems with the project shutting down previously or with it getting caught in a loop from a different corrupt file. In this case the file it’s citing might be fine, and it’s just the rtfi.exe in the Scrivener program that’s misreading it. In this case, it’s possible that uninstalling and reinstalling Scrivener would address the issue. In the former case, the problem is with the files in the specific project, so reinstalling the program won’t affect it. The size or length of the files shouldn’t matter.

It sounds like you’re back to normal with the project now, having restored from a backup? If that’s the case, it definitely sounds like the project had somehow been corrupted, e.g. from a computer crash or from some other software like a sync service or backup program touching it outside of Scrivener and disrupting the project. (Particularly if you have iDrive or Carbonite making online backups, I’d try excluding your Scrivener projects from that and just backing them up manually or making sure that the automatic backups are pointing to a location that is then copied as part of the system backup.) If you’re still running into the problem, you can send a zipped copy of the project to windows.support AT literatureandlatte DOT com and we can take a look at the problem files and see if we can get a better idea of what’s going on.

Thanks for the reply! Yes, I was able to restore the file from a backup copy.

I’ve noticed what may be a pattern in when I receive the error. It seems to happen after using the Project Statistics function (selecting multiple documents within the project and then using that to check the total word count).

Thinking back, I’m pretty sure I’ve never used the “Project Statistics” function until NaNoWriMo this year. Which is also the first time I’ve seen this error.

Of course, this does not necessarily indicate a causal relationship. Perhaps when Scrivener tries to calculate the Project Statistics, that’s when it notices the corrupted files? (And they were already corrupt?) Or perhaps it is causing the corruption?

I have used Carbonite in the past (earlier this year), but not recently (the past several months). My project file is on a USB flash drive, and then I manually copy backups from that onto my desktop machine. Maybe if I didn’t properly unmount the USB stick before removing it one time, it caused a problem? So many variables.

Next time I have the problem, I’ll send a zipped copy over for analysis. I had it again this morning, but “fixed” it before I’d read your post.

Thanks again, Jennifer!

Hm, odd. The Project Statistics runs a compile in the background, so it would be accessing files you might not have previously opened in this session but wouldn’t be writing to them. I’m not clear on when the message is occurring–do you actually see it pop up as a result of running Project Stats, or is it just that at some point later in the session after you’ve done that, when you then try to load a given document (that was part of the Project Statistics selection?) it gives you the error?

The specific error message is also new with 1.6, so there’s a smaller window for when you might have received that anyway–it could be you’ve had documents with problems prior to that, but the error checking just wasn’t in the program yet.

In any case, I’m glad to hear that you were able to recover a good copy. One thing to watch out for with the USB method is just that you’re not running into a situation where Windows is merging folders. If you move or copy a folder with the same name as one already at the destination, Windows combines them rather than completely replacing the original with the copied folder. That means any new contents get added and any contents with identical names get replaced, but nothing gets deleted from the original if it isn’t directly replaced. With that you can end up getting some mess within the project folder–not necessarily the problems you’re seeing here, but still issues you’d want to avoid that could end up with the project not opening or finding its files.

That may not even be a concern, depending how you’re copying your backups–if they’re all named differently, or if they’re zipped files, then there’s no occasion for them to be merged.

If you do end up needing to send a copy of the project, include (if you remember it) whether the documents with the problem were created fully in Scrivener (and which version, again if you can recall–even just knowing that they were made a year or so ago could give a clue) or if they were imported or had elements copied and pasted from other sources. The big thing is that every program encodes RTF differently, so right there you start out with complications. :neutral_face: Thanks for all the other info on the issue!