Heads Up. Working w/the latest version of 10.10 Yosemite Developer Release 3 and finding large documents don’t load in Scrivener. I get an unresponsive blank window (blank binder, blank editor, blank inspector). Smaller documents seem to open and edit fine.
BTW my manuscripts of 152,000 and fewer words open fine, but my documents of 180,000 word or more do not.
2.3 Ghz quad core 2011 MBP w/16GB RAM 1TB Hybrid Drive
There is a limited duration work around of copying the large document before editing and choosing the “Continue” option (to force a project re-index when Scrivener presents the warning dialog that this is a copy). This allows editing until the app inevitably crashes.
Yosemite is still in beta and has lots of bugs still, and Scrivener is not yet supported on it (it will be for release). That said, we haven’t seen any issues like this yet - I’ve opened some large files on there with no problem. Could you please send an example file showing the problems to mac.support AT literatureandlatte DOT com marked for the attention of Ioa?
Thanks and all the best,
Unfortunately, the document cannot be distributed. Here is a bit more info … Scriv version 2.5 (25236), there are 362 subdocuments in the Project, and I found another,more reliable workaround. Let Scrivener fail to open a duplicate of the original project (it fails to display it) and then open the original project either within Scrivener or from the Finder. This second attempt will load the project without issue.
I’ve had the same experience as Keith on this score. I in fact regularly work in the user manual project—it has ~1,300 items with a ~5mb search index (you can check that in the package contents: Files/search.indexes) and 255,000 words across the whole project—in 10.10, at least once or twice a day I’ll fire it up to make a minor typo change or add a note to myself.
One question, it sounds like you’re copying the project while it is open. Try not doing that. A project should never be manipulated in the Finder in any way while it is open in Scrivener. Ideally you should never see that “Continue”, “Make Copy”, “Cancel” dialogue box.
Overall though it has been rock solid (10.10 level instabilities aside). I don’t in fact believe I’ve even seen a crash coming from Scrivener, yet. I do run a pretty clean system during DPs though. So I’d do a little auditing if you’re experiencing repetitive and frequent crashing. Same goes for any OS, beta state or no. I’d clean out caches and do a little maintenance as well. I had a number of “upgrade glitches” that smoothed out after a little spring cleaning in ~/Library and removing most start-up software.
Clean system build on new hard drive as of last week, check permissions run a day ago, disk utility verify/repair run two days ago. I always close files before duplicating. When building this system, I did migrate over Scrivener Library data (w/Migration Assistant) that has continuously used/upgraded for 3+ years. A guess is that there could be some corruption in the project index inside the 243 MB package. Will keep monitoring w/future version upgrades … will let you know of any changes.
Regarding the project that can’t be distributed, what you can do is make a copy of the project and then use project replace on the copy to completely scramble the contents - changing “a” for “z”, “d” for “f” or whatever; after several random replacements the project will be complete gibberish so that it will contain none of the information, but should still exhibit the same problems.
Compressed version posted to Google Drive. See message sent to mac.support.
Removed the images and anonymized the text. Modified project still has opening issue on my machine.
Great app. Keep up the good work.
I had a second document fail to open and began to suspect my issue was not related to document size under Yosemite, but upgrade related issues affecting my particular application installation … e.g.User Library Preference Scrivener data corruption. So I attempted a clean re-install 1) under Preferences … Save copy of current theme settings and preferences, 2) Grep user/Library for all files/folders matching landl or scrivener, 3) move scriv data to a backup location, 4) move app to backup location, 5) re-install app from App Store.
Project opening issue went away. I can now open any project of any size …
with one new issue … preferences won’t save. I can’t save the backup folder location, reloaded theme and preferences don’t save.
I re-ran repair permissions.
I checked under Library/Preferences:
com.literatureandlatte.scrivener2.LSSharedFileList.plist was recreated
com.literatureandlatte.scrivener2.plist was Not recreated
I checked that the app is writing to the support folder
You won’t get any Scrivener preferences in the main ~/Library/Preferences if you’re running the MAS version. So that sounds to be expected. You will need to navigate all the way down to /Users/UNAME/Library/Containers/com.literatureandlatte.scrivener2/Data/Library/Preferences/ to find them.
It sounds like a permissions issue to me. Disk Utility does not repair inside user folders. I believe I recall there is a user folder repair tool in the password reset utility. You’ll need to reboot to the install and repair partition to access that. But it might be easier to just check the path chain by hand.
Another possibility is the pref caching system introduced in 10.9. I’ve had all kinds of problems with that. Preferences in general have become a lot more buggy in the past year or so.
Update - The preferences write issue is particular to the App Store version
I downloaded the literatureandlatte.com version of Scrivener and I am fully functional with no issues.
I have both it and the App Store version installed (renamed to Scrivener App Store). When I run the App Store version, the inability to write preferences problem is immediately visible (at app startup prompted w/dialog that “no backup folder has been selected” with option to select a folder that will not be saved). When I run theliteratureandlatte.com version … all is fine. Was able to restore and save all Preferences and Themes and am fully functional.