I was working in a project when in mid-typing it became “non-responding”. After closing the project down it would no longer open although I was able to open other, older projects.
In the process of backing up my work I found that one of the rtf files (391.rtf) would hang up the backup process. Long story short that file (and only that file) is troublesome. I can’t open it in Notepad or Word, nor can I copy, move or delete it. In looking at the other rtf files around the 391 number, I can tell from the text that the 391 file was definitely the one I was working on when the project became non responsive and I presume that the project won’t open now because the file is corrupted and the program hangs up on trying to open it as the current document.
Does anyone have a way to recover/repair this rtf file or provide me with a workaround that lets me reopen the project with all the remaining files?
I would check if you have any previous backups before this issue started. That seems like the safest way to go about it.
If you still want to try and repair the file, Word has a Open and Repair function. It might do what you are looking for.
With Word opened go to File>Open then you pick Open and Repair from a submenu, then choose your file in question. Here a link to Microsoft’s page detailing this function:
Thanks for that but regrettably that didn’t work. Word locked up as “non responding”. It’s kind of weird as I’ve had problematic files before but when this one is accessed it really shut’s down the calling program (whether Word or Windows Explorer or Scrivener or Notepad) in a very heavy way so that I sometimes can’t even shut the application down through Task Manager.
I do keep backups but the last one ran before I started working on that particular scene.
I have a workaround that’s satisfactory. I follow a style where I write in short chapters/scenes of about six pages or less and the subject file was only around three hundred or so words.
I created a new file folder changing the name slightly from the original project’s folder name. Then I copied all of the original project’s files (except for the corrupt one) into the new folder and in the new folder renamed the project .scivx file to the same name as the folder. i.e. folder and project file “Kestrel” became new folder and new project file “Kestrela”. I then copied one of the project’s rtf file at random, put it into a separate location, renamed it to the same name as the corrupted file (391.rtf) and moved the renamed rtf file to the new Docs folder. When I then opened Kestrela all of my project was there with the exception of the contents of the corrupted 391 file which instead, off course, duplicated the information from the randomly copied scene. From there I just deleted its text and started rewriting the contents of the corrupted scene from memory.
If this has taught me one thing it’s that my habit of writing in short chapters/scenes limits the loss from a corrupted file (not to mention that it helps in outlining and organizing the project in the first place and in making the final product more readable).
I’m sorry that you weren’t able to recover your file. On the other hand, I’ve been told by some prolific authors that sometimes it’s best to put a scene aside and completely rewrite it from memory. This lets you take the strongest parts of what you’ve already written (the stuff you remember) while molding it into something better using things in your head that you didn’t have the first time (while also keeping you from retaining things that you might not get rid of simply because you think that by writing it it must always be part of the story). I have trouble doing this myself, but this experience might allow you to gain some valuable insight into your creation process.
Very true. I treat my second draft as an opportunity to do just that.
Interesting aside. About a month or so ago I upgraded from Windows 7 to Windows 10 which I feel about 75% positive about. Some of what I’m looking at now has a bit of a Windows 8 look and feel to it and I’m still looking around for various functions that I used before (Don’t even get me started about losing the older version of Solitaire)
Anyway, since upgrading, I have twice had to deal with my Start Button and Task bar locking up and/or losing functionality (everything else continues to work fine). The first time I was able to fix it but the second time it persisted for the last four days and I was waiting for the next Microsoft Update to see if it would fix the issue. The Update came through a few hours ago and not only did it fix my Start Button/Task Bar issue but it also unlocked the corrupted 391.rtf file so that I have now been able to recover all of it and revert back to my original version of the project.
All in all what I’ve lost is a day of productivity.
Do you use file system encryption? I wonder if something went weird with that and ended up locking you out of the file—on the disk an encrypted copy of an RTF file would be ideally pure gibberish that nothing would accept as an RTF or be able to repair, kind of like what it sounds like you had. Well, I’m not a Windows user, so I’m just wildly speculating. :mrgreen:
For confirmation though: the procedure you used to recover the project is what we recommend as well. I’d personally go about it the other way around as it has fewer steps and is slightly safer: duplicate the .scriv project folder and then simply delete the corrupted RTF from the Files/Docs sub-folder rather than copying everything but the file into a new empty folder—but of course both have the same exact end result: resetting the text content for that item in the Binder. With the underlying .rtf file missing, the software just assumes it is a new file ready for typing, everything else you did to that item, such as adding a synopsis, or tagging it with keywords, will be retained since the Binder item itself is just fine. Hopefully that makes sense.
You will also want to use the Tools menu to rebuild the search index, after manually manipulating project data like that.
I do not use encryption and this is actually the first time in many years of usage that I’ve had any problem with Scrivener or one of its files. It’s a brilliant product in my mind.
Your method does sound quicker but I’m not sure it would have worked in my case because firstly the corrupt file crashed my attempt to back up the project so probably would not have allowed me to duplicate the project folder. In addition when I tried firstly to change the name of the project folder so that I could create a new one with the original project name to copy and paste things to, the rename folder action was also denied because the corrupted file was locked.
Incidentally I’ve worked with database files before where there is hidden cross-linking within component files that makes this type of recovery difficult if not impossible. I’m really quite impressed by the fact (and pleasantly surprised) that by simply transferring all but the damaged file to a new folder with the very minor renaming of the folder and project file would work so well. Probably not the reason why the program was built the way it was but nonetheless its an excellent by-product.
That accessibility of the project format is indeed part of its design. It was built around the premise that it should be easy to recover date from it, even with a total loss of software. That level of priority toward a human readable internal format is carried over into technical levels in the XML files that describe the system, using a sensible schema and descriptive meta-data. While skilled users can go quite a bit further with how much they can recover, even at a very basic level one has their writings in standard files, jumbled a bit though they may be. A nice side-effect of all this is that the format is fairly scriptable as well, for those so inclined.
Ah, yeah, if even the operating system couldn’t work around the file that leaves only your method.
I’ve now had my third event of an .rtf file locking up and basically shutting down while being worked on. I’ve never had this issue before. Only this last month since running Windows 10 and Scrivener 1.9.0.0 in tandem.
Literally the error arrives while I’m typing in the scene with Scrivener suddenly greying out and “not responding”. The most recent occurance happened when Scrivener was the only application running.
When it does happen I cannot shut down Scrivener even using the Task Manager and I’m forced to shut down Windows. On a restart, I can run Scrivener with another project but the project that was shut down by the file lock up remains locked. A search of the project’s documents folder shows that all the rtf files but one are accessible but the “locked” one is fully unresponsive and not deletable.
My first two “locked” rtf files were restored when Windows ran updates (I’ve had two run in the last two weeks and each restored functionality to one file). When the files were “reactivated” all the contents were there; there was no corruption within the file.
Anyone else with this issue? If so does anyone have a method for unlocking a locked rtf file other than waiting for the next Windows update?
I haven’t seen other reports quite like this, but there does seem to be a problem currently going round with Scrivener freezing when running Avast. If you have Avast, or a similar security program, try temporarily disabling it or whitelisting Scrivener to see if you can get it all working together.
Recently I also ran into a Windows 10 issue (three times) that causes the Start button and Cortana to lock up (and incidentally make all my taskbar icons disappear and lose most of its functionality). I followed an AVAST discussion thread on the topic which denied that AVAST was the problem and laid off the problem as a known Microsoft issue.
Regardless of who’s at fault, AVAST had a solution that allowed me to recover from the issue (beyond waiting for a Windows update) by cycling through a Safe Mode startup. The method is to call up the “Run” dialog by hitting the Windows key+R and then typing “msconfig” which calls up the “System Configuration” dialog. Here you select the “Boot” tab and then select “Safe Boot”. Save settings and shut down and restart. The computer will reboot Windows in safe mode at which time you repeat the process and deselect “Safe Boot” and again shut down and restart your computer which will this time reboot in normal mode. By doing so I recovered all my taskbar functionality and (surprise!), as a side effect, the locked .rtf file was cleared.
You might also want to try simply hitting Ctrl-Alt-Del to bring up the security menu, then choose Task Manager. Once Task Manager launches, choose File, Run New Task, and fill in explorer.exe then click OK.
This should cause Windows to re-launch explorer.exe – if it’s the first running copy, it will take over displaying the menus/taskbars.