I checked around but couldn’t find any posts that have to do with this problem. I apologize if it’s somewhere on these boards. I keep getting this error that says:
“Could Not Open Project. No valid Scrivener 1.x project could be found at the specified path.”
I have three WIPs and I was getting this error with my short story the other day. Fortunately, I had a backup and it’s working fine. Last night I was working on my novel. I saved it and saved a backup. When I went to open my novel just now I got the above message. The backup opens up fine but this problem is really scaring me. The project is clearly where it’s supposed to be so I don’t know what to make of this message.
This means that Scrivener cannot find the internal structure file necessary for opening the project (a .scriv package is really a folder of files, and this means that one of the crucial files cannot be found).
Are you saving on Dropbox at all? Sometimes Drobox renames files inside folders which can cause this problem - if Dropbox has caused it, it’s easy to fix, so let me know.
If I recall correctly, SugarSync does rename files when it gets confused, like Dropbox does. I looked up all of the popular Internet disk companies a while back to see how they handled conflicts, some rename files, others will pop up alerts and ask you to choose which file is the most current. If you have ever seen a dialogue like that, then it probably does not rename files. There are other things that can go wrong with services like these though.
That certainly sounds like the culprit. To check, do the following:
Ctrl-click on the .scriv file in the Finder.
Select “Show Package Contents”.
In the window that appears, look for a file entitled “binder.scrivproj”.
My guess is that it has been renamed (probably to something like “binder-mycomputername-date.scrivproj” or suchlike). In which case, rename the most recent copy back to “binder.scrivproj” and try launching again.
I tried your suggestion and it worked, sort of. First, there was more than one “binder-mycomputername-date.scrivproj” file. Since I had backups of my projects I tried renaming all of them in the one project (as “binder.scrivproj” “binder2.scrivproj” and “binder3.scrivproj” and deleting all but one in the second project. Both projects opened but there were a number of recovered files which turned out to be documents I’d worked on during my last session and were now out of order, etc. Should I have done something different?
Rather than try to reorganize the recovered files to their proper places I elected to delete the project and use the backup copy. I don’t mind making backup copies but it seems silly to have to essentially save the project twice just so I can open it again.
Since it appears my backup method is the problem here, is there a backup method you guys would recommend which wouldn’t rename the files (and make extra random copies)?
Also, to answer AmberV’s question, I do NOT get pop up alerts from Sugarsync asking me what to do about duplicate files.
It’s really best to keep your working projects outside of these Internet synchronised folders, as there is a medium to high level of risk with running into problems like you’ve experienced. The best way to use Dropbox, SugarSync, MobileMe, and so forth is to save zipped backups to them, but to work in folders that are outside of where they operate. With SugarSync this is more complicated since you can designate areas of your user folder by design (with Dropbox you are limited to one folder). So you might need to take a look at your configuration options and find a place where you can safely work.
As for the best way to keep backups. It’s recommended to use the File/Backup Project To... menu function with the zip archive checkbox on. This will save your project into a single file, which is much safer to use with these sorts of services. This is exactly how I use them. I love Dropbox, but I only ever use it to save zipped backups and I keep my .scriv files all located outside of the Dropbox folder.
It is possible to fix a project that has been tampered with like this, but as you note it takes a little deciphering and piecing back together. If you have a recent backup it might be an easier option.
If you absolutely must use SugarSync with live Scrivener projects: try setting the autosave (in General preferences) to a higher value, and always be absolutely certain the project has been closed on other computers, and that whenever you are done for the day, wait until SugarSync has completely finished uploading the project file changes, before sleeping the computer or shutting it down. Conflicted files like this most often happen when one computer hasn’t finished uploading, then a second computer changes them, and when the first computer gets back online, it notes that some of its scheduled uploads are modified as well (they haven’t been uploaded yet). In ordinary cases of files and folders, this is a safety, as it lets you open both versions and sort out the differences between them. With an orchestrated multi-file format like Scrivener, it can wreak a little havoc.
What probably happened here is that the binder.scrivproj file from computer B was a little older than it should have been, and didn’t recognise some of the newer files you’d created on computer A—hence “recovered files”. These are created whenever files exist within the project bundle that are not recognised as being a part of the Binder.
It doesn’t really say anything more than what I’ve said here, but this advisory, and the following discussion, might be of further assistance.
Thanks Amber for the link and the extra information! I only have one computer but have a habit of putting my computer to sleep right away when I’m done with my project for the evening so I’ll try waiting a bit before doing that.
I’ll most certainly be saving my projects to a USB drive and zipped up.
Yes, it is certainly possible (as you can see) to replicate this set of conditions with a single computer. It is however much easier to accidentally do so with more than one, hence my assumption. Anyway, sorry you ran into this problem. Scrivener’s project format was designed before any of these systems became popular (iDisk was around, but not commonly used), so it was never really architected with something like this in mind. Steps are being taken to make the internal format more robust in the future.