Yes, the system does tend to generate a crash report. In fact Scrivener looks for any pertaining to it when launching. If you haven’t restarted yet you could try that, and you’ll find the report along with an option to send it in. But if that didn’t work (or just as a general tip since not all software has that), open Console from the Applications/Utilities folder, and check the crash logs section in the sidebar. Sometimes you might find them in diagnostic reports, too.
Can I set up auto saves to prevent further data loss.
Scrivener auto-saves by default. You should be fine unless there are issues with where you chose to save.
It is regular old auto-save (like many Mac programs do these days), which means it saves over what you have open rather than spawning a stream of new copies somewhere that you have to clean up later.
You can read more about backups in §5.2, Backing Up Your Work, in the user manual PDF. That should not be confused with saving.
This is the only application that ever crashed on my Mac??
Could be important, could not be (for example some people say, only Scrivener does this, and when we ask what else they use they list a bunch of non-Mac software like MS Word and Chrome—but even if all you use is Apple software it might not mean much other than the fact that Scrivener is using some corner of the OS you don’t use with anything else, like its embedded movie player). It’s not really possible to say without information on how it happened. I would start by browsing the crash tag here, within the Scrivener > Scrivener for macOS section, and look for similar sounding conditions.
I found the error log, thanks, but I’m unsure what to do with it.
You can attach it here, as a .log file, by dragging it into a response. Feel free to send it to my account directly, if you are unsure of whether it contains personal information.
on re-opening Scrivener I had lost the work I had done and only had the save from the afternoon session, which was made when I manually saved and did backup etc.
Ordinarly auto-save will trigger after two seconds without any activity (the setting for that is found in General: Saving). It is possible for a swift writer, that rarely pauses to think, to auto-save less often—but two seconds really isn’t that much! Most of the time when people manually save, they aren’t doing anything at all, because by the time they got the mouse to the menu command it has already saved.
A larger loss than a few sentences (especially if you were manually saving) is extremely abnormal, and could indicate some deeper problem with the location in which the project is being saved. If this location is suffering disk errors for example, or if it is on an external drive, a bad USB cable, something like that could even bring on a crash.
I’d certainly try working from another location for a bit, and perhaps run disk diagnostics on the place where it was located. It may be perfectly fine, of course, but that’s not the kind of thing you want to gamble on.
Thank you. I will send it to you as advised, maybe it will highlight an issue to prevent future instances of this occurance.
It can help, but what we really need is the sequence of steps leading up to the crash, and ideally in a way that repeating those steps always causes the crash.
If it happens a lot, start looking for patterns. Thanks for any help you can provide!
the Autosave was set to 720 seconds, so it probably never kicked in.
I’ve adjusted to 20 seconds.
Im having an issue setting backup and save locations. Well, actually backup goes where it’s set to but save goes to the same place? I can save As and it goes to where I want it, but just using save goes to my backup device.
Ive just spent an hour figuring out where different options save to but its still not clear.
Online information suggests that a backup exists in the library/application support folder, but a Scrivener folder is not present at this location.
Save: Save As: Close: Backup Now: Backup to:
could you enlighten me as to the intended behaviour, or perhaps advise how I can set the save location.
thank you for the fast replies and valued support.
Ah yeah, that definitely would make it so it very rarely saves. Well that’s not good news as it means the stuff you lost with the crash is certainly gone, but there is at least a silver lining anyway in that it means your drive is probably fine!
Even 20 seconds is a pretty long time for an idle timer. Bear in mind it only kicks in if you haven’t done anything in the window for that period of time. The default of two seconds is usually fine because it only takes a fraction of a second to save.
The common reason you’d want to increase it is if your natural rest/work cycle is such that you consistently find text input lagging when you start typing again. In such cases I recommend people try bumping it up a couple of seconds, see if that works better, then a little more if not, etc. Small tweaks are better than big ones. The main reason to use a really long idle timer is if you are working off of a relatively slow location, like an NAS. But then you have to be more mindful of the fact that it will probably not often save, and do so yourself when you have a natural break.
Online information suggests that a backup exists in the library/application support folder, but a Scrivener folder is not present at this location.
The most reliable way to find your backup folder is with the button in the Backup settings tab. For the overall Application Support folder, use the Scrivener ▸ Reveal Support Folder in Finder menu command. If you purchased from Apple, it won’t be in the standard location, but rather buried deep in the sandboxing area of the Library folder.
And yes, you definitely don’t want to be working straight out of your backup folder. Your working project should be located somewhere else, like ~/Documents. You could use Save As, but moving it with Finder while it is closed is a better bet. Save As leaves a copy behind, which can get confusing (especially since “Recent Projects” keeps track of both at that point).
The logic is pretty simple though: you put your project somewhere easily accessible, like a normal document. You double-click on it in Finder to open it, and that is where it saves as you work. Backups are made depending on your backup settings (typically only at the end of session when you close it). They save to a separate location you would ordinarily never access. They are just a little extra protection on top of any other backups you use (like Time Machine).
Okay, I’ve had a look at the crash logs you sent. This definitely looks like a bug we are currently in the process of gathering information about. The code that is crashing is all within core Mac libraries that operate on images, and it seems to be stumbling over the process of trying to write a particular image. Here is the part that is typical between cases we have seen:
Be much better if you put it back to the default/recommended 2 seconds. you will never notice the performance hit and less work loss if there is an upset. This automatic saves when there is inactivity, e.g. you stop for a moment to think, stretch, or sip your coffee.
Okay! Well then as a simple test, I would first use the File ▸ Back Up ▸ Back Up To... menu command to create for yourself a separate stand-alone backup file you can return to, if for some reason you ever want to return to the project as it is, that will be your return point. I recommend using the .zip option so it cannot be accidentally opened directly.
Now for trying to find what is causing the problem, here is how I would go about it:
First, go through each binder image one by one. Just clicking on them is fine. I doubt, given the error, that these are involved because Scrivener doesn’t edit them, it shouldn’t be trying to write them—but you never know. What we might be seeing above is the operating system trying to write the image to a temporary cache location. If you get a crash at any point, then do this:
Open the project again, and use the Navigate ▸ Editor ▸ Lock in Place shortcut. Now you can select the image that caused the crash without it actually loading.
Trash it, and then empty the trash.
Alternatively, if this is your only copy, you could use File ▸ Export ▸ Files... to try and get it out. That might crash though! If it is really important to not lose it, let me know.
Turn the lock back off and continue (in case there is more than one).
Next you’ll need to basically do the same with the images in text files. The Edit ▸ Find ▸ Find by Formatting... tool, set to look for “Images” is going to be the most convenient way to do that. Select the very top item in the binder, and then click “Next”. For each image it finds:
First, position the cursor above the image it found, and type in a letter, waiting for auto-save to kick in (here, setting it back down to 2 seconds will be much better for you).
If that causes a crash, then you know one of the images in this section is bad. Remove each, one by one, repeating this single-letter auto-save test.
Some general tips & notes:
If you hit one bad image, you might consider stopping the test for a bit, and just working normally. Chances are very good that you don’t have multiple corrupted images in the project. These are not really that common. That said, the fact that we are seeing more of these crashes in recent macOS updates indicates the problem may be more than typical image corruption—it may be a type of image that the Mac update made unstable, that used to be fine. So if that’s the case, there might be many of them. We know very little right now, all we know is that it seems like a recent Mac update has reduced image handling stability. Is it purely in the Mac image handling framework? Is it something we were doing in the past that is now discouraged and causing problems? Did Apple forget other developers exist and break something we all use without testing it (you’d be surprised how many bugs come down to that!)?
Me, I’d want to not spend hours going through every image. Might as well see if removing one bad images fixes things. If not, you can pick up the checklist again.
If you end up in a situation where the project crashes on load, it might have auto-saved your position in the binder before it crashed, and now whenever it loads it goes straight to the bad image and crashes again. Follow this checklist to reset the user interface. One thing this reset procedure does is ensure nothing is loaded in the main editor, allowing you to use the “Lock in Place” trick to deal with the thing that was causing the crash on load.
If a text section crashes the moment you click on it, we’ll deal with that. I’m hoping it actually is just on-write though.
I have reduced the Auto Save parameter and managed to set up different locations for Save and Backup. I also did a sync to another external drive but it creates individual files rather than a project file or ZIP.
I will invest some time checking for the suspect image tomorrow.
Thank you for all your expert advice, guidance and very efficient with regards timely responses.
Note: Sync is not backup. Sounds like Scrivener did what you asked, intended or not.
The Scrivener setup for backups allows you specify where they go, how many backup copies to keep, and to “zip” the many files into one file. Zip files recommended not only for disk space, but having the entire project compressed into a zip many feel is more secure than scores/hundreds/thousands of files. I’m one of the “many people”.
Something that just came up is that one of the people experiencing this crash indicated part of the problem may be down to how the Mac handles cloud sync with some services, such as Dropbox, OneDrive and iCloud. If you have your project stored in an area that is synced, one very simple thing you can try is to move it to a location that is not synced.
A local disk, or more likely areas of it, can still be synced by a cloud service. For example iCloud Drive imposes a soft default of syncing everything in your Documents and Desktop folders, which most people would think of as “local”. If you use iCloud Drive, a simple and safe way to ensure something isn’t syncing is to move it to the top level of your home folder temporarily, or to an external drive.
But if you are positive it is not being synced, that is fine, it is just a clue—a thing that helped one person get rid of the crashing somehow (honestly it makes no sense that syncing would disturb how images are loaded at this low of a level, but Apple’s sync infrastructure is chaotically complicated, so who knows). It may not work or be relevant to everyone.
