I added a large video to the Research folder of my project and then realized that the video was saved in the project rather than just a link to the file. I therefore deleted the video (moved to trash and then emptied trash) and saved the project.
When I closed the project, I noticed the automatic backup took a REALLY long time. I was therefore suspicious it was still backing up the video.
When I opened the project again, I received the below “Files were recovered” error message. Given the fact that this project is stored in Dropbox, I thought that might have caused the problem, as mentioned in the error message.
I therefore paused Dropbox sync, deleted the recovered video file again, emptied the trash, and saved and subsequently closed the project. Backup took forever again, indicating video still present.
I opened the project again, and sure enough, received the “Files were recovered” error again. The large video file was returned to my project.
I’m therefore unable to delete this video and minimize my project storage size. It also appears that this is not cloud-related, as my Dropbox sync was paused during this testing.
You can manually delete the file via: Binder > Ctrl + Right click (on the document) > Reveal File Location.
This will open your document folder.
Close Scrivener and delete the video file revealed in Windows Explorer. Now you should be able to Trash the document inside Scrivener as usual.
If you pause Dropbox sync’ing, then delete a document in the project on your desktop, it will still exist on the Dropbox server, so when you re-activate Dropbox sync’ing it will see that there is a difference between the two versions and import the offending file back into your desktop version as a recovered file!
The problem in this case was indeed caused by the Scrivener media player not unlocking the file. Because of this deleting the file was not successful upon emptying the Trash. If you load another media file in the Scrivener editor(or restart Scrivener and never load the media file), and then empty the Trash, most likely it will succeed.
This has been fixed and will be available in the next update.
Thanks, xiamenese, for the idea on Dropbox. Unfortnately, the problem was still occuring even though I had never re-enabled Dropbox Sync, so that wasn’t it. I appreciate the idea, though!
Thanks, Tiho_D, for tracking down this bug and slating it to be fixed in RC2.
Sorry, Tiho, I never saw your reply to that message until now. I will take this as a more comprehensive error report and look forward to a fix in RC2. My problem was only ever recovering blank documents so the impact on time and memory is insignificant.
