I’m glad there a few other non technical types here 
I was trying to backup to a thumb drive, but Scrivener told me something along the lines of :- unable to backup. I assumed the thumb drive was full. It wasn’t. And in the meantime I discovered that what I thought was being “saved” as I went along, wasn’t. (I think I have worked this bit out from the other post here. Thanks.) Anyway, after telling me it couldn’t save, the whole thing froze. The only thing I could do was Force Quit. I’m also a new convert to Macs… courtesy of Scrivener and Curio.
Is this something I’m doing wrong … very possible… or is something else going on… besides the technically challenged person in front of the computer, I mean.
Luckily I didn’t lose so much that I need the clever find it again suggestions you posted for the other query. My sympathy to the other writer who lost their brilliant words.
Thanks in advance.
If you get the “unable to backup” message, it just means that Scrivener couldn’t save the file to thumb drive. Scrivener has no idea why, though. It uses internal OS X file system methods to write to disk - these methods just say “YES” if it worked, “NO” if didn’t, and don’t provide much more information, unfortunately. So, if the file system tells Scrivener, “NO, couldn’t write to file,” Scrivener passes that back to the user as it’s the only information it has. Thumb drives can be a bit temperamental at times, mind.
As to why it then refused to save - well, that is strange, and obviously shouldn’t happen. If it happens again, open up the Console program, which you can find in Applications/Utilities. When a program stops working properly, it often spews out error messages to the console, and you can see them there. They won’t mean much to you, but you can send them along to me so that I can see what is happening. Also, if Scrivener actually crashes - or if you force quit and receive the “closed unexpectedly” message - copy the crash report and send that to me, too. That way I might be able to work out what is going on.
Thanks and all the best,
Keith
Finder has a bad habit of letting you think your drive is empty when it isn’t. Here is why.
Much like the windows recycle bin, the “Trash” can in finder does not immediately delete your files. Way back in the days of 7" black and white screens folks realized that it was easy to accidentally drag files to the trash can. So they tie the trash can to a folder on the disk the original file is in. Technically this is .Trash in the root of each drive. Hopefully you will never need to see that again. Here is why, all you need to do is empty the trash.
Plug the thumb drive back into your mac. Now empty trash. Now try saving to the thumb drive.
Remember that you don’t delete a file, or free up space until you empty the trash.
If you are still having problems let us know and I am sure one of us will come up with another answer for you.
This is rather worrying. I’ve been trying out Scrivener on by MacBook Pro, and created a new test project, to use alongside the tutorial. I made some changes, moved pages around and added some folders. Then it popped up a message “Unable to save”, presumably in response to an attempt at autosave. Same message when I tried to save explicitly. Then I tried Backup Project To…, and got “Unable to backup”. A few seconds later, the project suddenly disappeared, leaving the Tutorial still running. When I tried to open my test project, it contained my first few edits, with most of my recent session gone forever.
My HD has 23Gb of space on it.
I don’t think it’s acceptable to blame the filing system when this happens. There were no relevant messages in the Console log. Something could have happened within Scrivener that stopped it saving. The possibility of such a serious bug means that I’m not able to have confidence in what otherwise looks like a very good tool. 
Please let us know when this bug has been tracked and fixed.
Well, if you can give more information it would really help in tracking and fixing anything that may be wrong.
The “cannot save” and “unable to backup” messages occur when Scrivener calls on the OS X file saving methods to save a file to disk. These methods - a core part of Cocoa written by Apple - return a simple “YES” or “NO” telling the developer whether OS X was able to write the file or not. If it returns “NO”, I have Scrivener generate that error. No other information is provided.
Usually this would be because you don’t have the correct permissions, because the disk on which you are saving has run out of space or something like that. This error is extremely rare. I would therefore ask exactly where you were saving to, what disk space you have left or for any other information you may be able to think of that could explain a file saving problem on your Mac at that time.
I’m not ruling out the possibility that something is going wrong in Scrivener - it would be irresponsible to do so - but I am being honest about how these methods work and why these messages appear, which is why any more information you can provide would be useful.
Regards,
Keith
Hello Keith,
Thanks for your speedy response. On my test document it’s just happened again, so I can tell you that the precise error message is “Error Saving Project - There was a problem saving the project.” And the same message, along with a “Backup failed” message when I tried to do a backup. I’m trying to save to a sub-directory in my home folder, with 23 Gb of disk space.
This time there are nine instances of the same message in the console log, over a four minute period that I tried to save:
Hope that helps. Is there anything I can do to help you track the problem, before closing down and restarting Scrivener?
Best wishes, Rob
I have never seen that message before (it’s from deep in the Cocoa frameworks judging by it) and a Google search doesn’t help much.
One thought before continuing: you haven’t accidentally moved this project to the Trash, have you, by any chance? I ask because this did happen to one user once before now I think about it - he had moved his project to the Trash and then tried to work on it; but you can’t save to the Trash.
All the best,
Keith
Sorry, Keith, I have now checked that. My project is on the main hard disk, not in Trash, and not trying to save to a disconnected external drive. I will restart Scrivener now, and hope it doesn’t happen again. The dialog box saying “Backup Failed” will now not close. I can continue using the menus, so it isn’t modal, but the OK button on it does nothing and I can’t get rid of it.
Best wishes
Rob
Are there any other errors on the console from earlier in its running? Is this problem happening with all projects or just one?
Let me know if the error continues after restarting and we’ll take it from there.
Thanks,
Keith
if you are comfortable in terminal and do
df -klMake sure you have free space. Look for something like
Filesystem 1024-blocks Used Available Capacity Mounted on
/dev/disk0s2 116753840 59798220 56699620 52% /I just noticed on 10.5.6 that the trash for my small thumb drive (64MB) was on my internal drive. My 1TB external is NOT showing that behavior. Maybe you do have a full disk but as I noted in an earlier post finder is not reporting it as it is all “trash” that has not been emptied from the correct drive.
Sorry if I am chiming in with the obvious, but have you tried creating and saving files with other programs on the same drive?
From the description, a disk or permissions error still seems most likely, so I am just wondering if it might be more general than just scrivener. Do you have any other programs that save files in a package format that you could test with?
Apologies if you have eliminated this already.
Matt
Another thing to check the next time this happens. Cmd-click in the window title area and select the folder containing the Scrivener project that is giving you problems (this will also reveal any weirdness, if for some reason the project is not where you think it is, as it presents a full hierarchy list). You should get a Finder window with the project selected. Press Cmd-I to get info on the project and expand the Sharing & Permissions section. On Leopard, you should see a list in a table split between Name and Privilege. Your username (short form) should be in that list and associated with Read & Write privileges. If not, then you have something weird going on at the filesystem level.
Do you have any sort of maintenance or cleaning applications running in the background? I use Hazel, and the only time I’ve seen this message is when I have a test project open in a temp folder that gets auto wiped periodicially by Hazel checking for a +3 hour mod time. Once the project lands in the trash, it malfunctions. Now, you say Trash isn’t the issue here, but maybe you have AppleScripts or other applications running maintenance routines and changing permissions.
No other relevant errors. Lots of presumably normal ones, but not to do with Scrivener.
This is the only time I’ve seen it happening.
df -kl
Filesystem 1024-blocks Used Available Capacity Mounted on
/dev/disk0s2 195025072 171886536 22882536 89% /
Yes, I’m doing that all the time: I’m a Python developer.
Please could you suggest some common programs that might be similar.
@AmberV
Thanks for the suggestion. I’ll try that if it happens again.
Not that I’m aware of.
Thanks for the help and advice. I’ll carry on testing it over the weekend.
Best wishes
Rob
12,
Are you using an admin account? Also in terminal, as the user that runs scriv, check your quota. Shoudl be something like
Last login: Fri Mar 20 16:37:57 on console
mac:~ jaysen$ quota
Disk quotas for user jaysen (uid 502): none
mac:~ jaysen$ Based on your df you are at 10% free space which confirms the finder. That is good. I believe the reserved fils space limit on HPFS is 2% so you should not be getting anything due to that. ONly other thing I can think of is if you created the scriv file as one user, moved it to the shared folder then opened it as another. If you are like me you use different accounts at different times of the day to separate “real job” from home. I do all dev and admin under a different UID and if I create a package under that UID it must be created in the shared folder. Apparently finder does not apply the shared permissions to the internal files creating problems similar to what you are seeing (i had this what a VM under parallels, talk about a PITA to clean up!).
Anyway, still thinking. I am sure something will make sense soon.