You’re totally right, although there are cases where “backup to” might actually work. The outcome depends on the memory state Scrivener is in. Given that you have worked on all files in your project in the current session, there’s a chance that you can still save the whole project even without getting an error message. The chances are obviously zero for big projects. 
I’m curious about this because one day I too would like to get a shiny new MacBook. So I went to the Scriv preferences pane to see where you would specify where your current projects would be stored–presumably on the macbook itself, as I think that would just solve Alison’s problems–and I couldn’t find anything. Strange. Is it just in set-up that you determine this?
I remain a clueless and avid onlooker to this discussion.
Not in your preferences panes or the application set-up, Zoe, but when you start a new project, you’re asked what name you want to give it and in which folder you want to save it.
I have folders and — sometimes — sub-folders set up in the Finder for each writing project and keep all the relevant materials, Scrivener projects and relevant documents created by other software in them.
H
Once you have your new MacBook, I would recommend to use Apple’s Migration Assistant to transfer your user account(s). This is usually the easiest way to move your data from one Mac to another. It also does a lot more for you than just copying your Scrivener files (i.e. applications, license information, adress books, calendars, bookmarks, etc).
How good to see you, Hugh! 
And it just goes to show how long it’s been since I started a new project. 
I do remember that now.
Signinstranger, I just bought my daughter a brand new aluminum Macbook with Leopard on it as a graduation present to replace her old (vintage 2003) apple laptop, on which she was running Tiger (as am I, on my lamp–the old G4 with the swivel flat screen which I adore but which is aging rapidly). To our mutual dismay, she learned that Migration Assistant does not work for transferring from Tiger to Leopard, and she just had to copy everything over via her external hard drive. 
I’ve learned since that it’s not a good idea anyway to use Migration Assistant to transfer from a PPC machine (which we both had) to an intel one (which her new laptop is, as will mine be, if I ever sell this magnum opus). So “building from scratch” it is and will be.
MM: I’ve had no trouble copying projects from an external drive to a new location and opening them with a new version of Scrivener (might get an upgrade message).
-Steve
I tried this and I get two error messages. One says “Backup Failed” and the other one says there was an error. And the “Backup Failed” one won’t go away. The “OK” button isn’t lit and nothing happens when I click on it. I can move the box around but not make it go away.
Now, I made a backup of the project yesterday to my dropbox. Should I just drag that out to the Doc folder and open it from there? That’s essentially doing what I’m trying to do, right?
Yes. As the earlier posts indicate, the failure messages are signs that you probably opened the file on the external drive and didn’t save before disconnecting the drive. I don’t know much about dropbox, but make sure a copy remains there.
Good luck!
Okay! I think I’m back in business. I successfully saved it to the folder where I want it to be, and I’ve made some revisions and tried saving and it worked just fine. Thanks for all your help!
Hi alison,
Just to avoid any similar problems in the future, I would suggest you should do a couple of things now:
-
Read through the explanation of why not to work on Network drives etc. in the link I provided above.
-
Use the “Backup to…” option regularly, and select the option to save as a Zip file. Keeping regular backups is good practice anyway, and the backups will be dated for you to make it easier to go back to an earlier version if you need to.
-
Whenever you transfer Scrivener files between computers, or whenever you put them onto DropBox, always use a zip file instead of an uncompressed project. This is because DropBox etc. treats a ‘package’ as a regular folder, and it can get more complicated for it trying to work out what has or hasn’t updated, and you have the risk of everything not being synchronized (half the files might have updated, and not the other half, and this is where Scrivener can get in a confused state).
By using a zip file, you are guaranteeing it will all be treated and transfered as a single unit.
Matt
Hi
I’m getting similar problems routinely and it’s quite alarming. I think it must be to do with the fact that I use Synchronize Pro to synchronize my data from my home computer to my work computer (via a memory stick). I’m now, fairly routinely, getting the error message “The project you are trying to load uses an older format and cannot be opened…” and empty projects and empty files. Previously I thought that the problem could be solved by ensuring that Scrivener was shut down before doing a synchronize but I suspect now that it’s more than that. Perhaps a protocol might be posted on FAQ or somewhere on the practices that should be followed to avoid this problem? Or maybe there should be some way to recover a project (the project I have is 7.1MB and it appears lost unless I can find an old version on Time Machine).
Donncha
Amber has already done this. This appears as a sticky above the tech forum. Here is the link:
Apollo16
Thank you all. The health warning applies to synchronizing using software like Synchronize Pro as well as server based synchronizing systems like DropBox. However, I work so much between two computers that I’ll just keep synchronizing and make backups as routinely as possible.
Donncha
To clarify I have never posted anything in regards to avoiding synchronisation software. Of course these applications should always be used with care to make sure the right stuff is going “left” or “right” as the case may be, but otherwise I myself have not had problems with them. That said I have not used Synchronize Pro. I’ve been a Chronosync user for years now; never had a problem with it. It might be that the software you are using is using a less safe method for copying files. Chronosync uses a technique which transfers the file to a temporary location on the target volume first, since this is the most error prone part of the process (moving data between physical devices), and then does a thorough comparison of the copied temporary file with the original file. Then, after doing that, it moves the file to its intended location. Moving a file doesn’t actually transfer any bits from one part of the physical device to another. It is entirely a process of the file system, which tells the computer where files are located physically. I realise I’m getting a little geeky here, but the summary of what I’m getting at is that the mirror process is very safe, and throws a lot of errors if it messes up at any point. You can check the documentation for your software and make sure it is using a safe method like this. Another thing to check: Chronosync has an option for doing package level synchronisation. It will look into bundle formats and treat them like folders of files. This can save synchronisation time. If you have a huge Scrivener project and you change only one small thing in it, at the package level the entire thing would need to be transferred. At sub-package level, only the parts that changed will be transferred. However, I have run into problems using this features. A Scrivener package is a very integrated set of files, part of what makes DropBox risky applies to using sub-package synchronisation. If you have the option to disable that, turn it off. It will make synchronisation longer, but I’ve never had a fouled up mirror in all the years I’ve been using Chronosync with that option off.
And of course, using these programs to propagate one-way backups is even safer. The trickier thing is two-way synchronisation.
Thanks for that and apologies if I was inappropriately extending your health warning to synchronizing software. I’m doing two-way synchronisation with Synchronize Pro X(Version 5.0.7) and I’m certainly having problems - albeit intermittently - around it.
To clarify the problem: When I synchronize to my memory stick, the file on the memory stick is 7.1 MB while it should be 8.9 MB and when I try to open it I get the following error:
"The project you are trying to load uses an older format and cannot be opened. Would you like to update it? A copy of the old project will be saved in the same directory.
IMPORTANT NOTE: If you choose to update this project, make sure that you do not try to open the updated project using a version of Scrivener earlier than 1.10. Versions of Scrivener earlier than 1.10 will mistake the newer format for an older one and offer to update it - but doing so will corrupt the file (although a backup will be created which will still be usable)."
Updating only creates an empty project.
Sometimes I don’t get this error but some of the (pdf) files in the copied scrivener project are empty. And then sometimes Synchronize Pro copies the files over accurately and completely. As I say, it’s an intermittent problem.
I’ll investigate Chronosync as an alternative because the problem is a bother.
Ta
Donncha
Another thing you should check is your flash drive, those things can wear out after a while (they are based on a chemical process, so like batteries they get used up). I have seen symptoms like improperly copied files before, on older devices. JPEGs that are half garbage and so on. Flash drives are cheaper than software, so that might be a better place to start—though Chronosync does have a trial period.
ta; will do.
Problem hasn’t reappeared with new flash drive; fingers crossed.
Could a ‘recover project’ feature be added to Scrivener? This might only be an option with errors like “The project you are trying to load uses an older format and cannot be opened…”, and it wouldn’t guarantee full recovery, but at least the user wouldn’t be faced with the prospect of losing a complete project.
It is still an excellent piece of software.
Donncha
There are already some substantial recovery mechanisms in place (check in your Binder for recovered items, these are bits of the project that Scrivener found in the package file and doesn’t know what to do with) and in your Documents folder, which might contain bits of projects that are in trouble as well. The next version of Scrivener will be even more robust about this kind of stuff.
The problem with projects that have blank documents and so on is that, well that’s actually what they consist of. If you open up the project bundle and read the actual RTF files that make up a project, they’ll be blank too. So there really isn’t a good way to recover from that, short of using back-ups from when the project was healthy. If your old Flash drive was writing incomplete or corrupted RTF files, there isn’t much Scrivener can do about it, I’m afraid.
2.0 has an “Import Scrivener Project” feature which will work with corrupted projects that cannot be opened too - it won’t be able to import the structure of corrupted projects, but will at least recover the files, file titles, synopses etc.
All the best,
Keith