New beta build of El Cap, and Dropbox

Not sure what the problem is, I filed a few reports to both Apple and L&L. Here is the story. I downloaded the latest beta build of El Cap. Then I opened a .scriv file in Dropbox. The app crashes. Then the window to file a report to Apple pops up and I duly do that and then click reopen Scrivener. App opens without crashing. Try to reopen that Dropbox file, app crashes. Then I go through the motion again and this time, after ckicling reopen and having Scrivener up, I try to open another file in Dropbox. App crashes one more time (so, it wasn’t THAT first file). I go through the motion again and now, after clicking reopen and having Scrivener up, I create a new file and save it on my desktop. It’s fine. I can work on it, and save it, and close it, and reopen it. Then I copy one of the .scriv files that previously crashed from Dropbox to my desktop. I open it, and it works fine. Then I copy this file onto OneDrive, to see what happens with another cloud service. File opens fine again. It does look like there is an issue between the new beta of El Cap and .scriv files sitting in Dropbox. At any rate, both Apple and L&L have the crash reports and so they will investigate by reading them

EDIT: it does look more complex than that. I can open some other .scriv files in Dropbox. I also get some weird messages about .scriv files opened in some other devices and I know for a fact that that’s not true. So, there may be an issue in completely closing a .scriv file. Not sure. Puzzled

EDIT2: now the .scriv files in Dropbox that previously made the app crash, open totally fine! Go figure. The only thing I can think of is that at some point, while using one device (MB12") to open a .scriv file in Dropbox, I noticed on another device (Mac Mini) a Dropbox notification regarding a file created (or modified) in Dropbox and called ‘lock.user’. Is there the key to the mystery? I don’t know. Now it does look like I can work on these Dropbox files and Scrivener does not crash.

The perplexing thing with all of this is that there is no such thing as a file being “inside” one of these services, that isn’t how they work. They work by being given a folder on your disk, and within that folder they have full to power to change, add or remove files based on whatever the server tells the computer to do. Thus, the Dropbox server says “add this file with this data” and your computer downloads the data and makes that file. At that point, it is just a file, in a folder, like every other file on your computer. If you copy it from the Dropbox folder to Documents, the files will be 100% the identical save for their paths being different.

Given that’s the thing that changed, it could be some odd state or preference related glitch. Whatever it is, it seems to be a very fragile condition if so much as copying a file to a different folder solves it. I’d try renaming the project in the Dropbox folder and see if it accomplishes the same thing.

yeah, i know, it’s pretty bizarre. the only thing i can say is that it seems a transient thing that fixed itself. i have four crash reports but now all seems fine. i do get some scrivener-related messages in the console but I can’t say whether they were already there before the new update. since everything worked well i had no reason to check. here is what i get, if it is of any help (I doubt it):

11/17/15 5:15:22.807 PM Scrivener[2495]: NSSoftLinking - The ShareKit framework’s library couldn’t be loaded from /System/Library/PrivateFrameworks/ShareKit.framework/Versions/A/ShareKit.
11/17/15 5:15:23.243 PM Scrivener[2495]: WARNING: The Gestalt selector gestaltSystemVersion is returning 10.9.2 instead of 10.11.2. This is not a bug in Gestalt – it is a documented limitation. Use NSProcessInfo’s operatingSystemVersion property to get correct system version number.
Call location:
11/17/15 5:15:23.243 PM Scrivener[2495]: 0 CarbonCore 0x9ad49913 ___Gestalt_SystemVersion_block_invoke + 135
11/17/15 5:15:23.243 PM Scrivener[2495]: 1 libdispatch.dylib 0x918e4763 _dispatch_client_callout + 50
11/17/15 5:15:23.243 PM Scrivener[2495]: 2 libdispatch.dylib 0x918e463f dispatch_once_f + 78
11/17/15 5:15:23.243 PM Scrivener[2495]: 3 libdispatch.dylib 0x918e5ec9 dispatch_once + 31
11/17/15 5:15:23.243 PM Scrivener[2495]: 4 CarbonCore 0x9acc5576 _Gestalt_SystemVersion + 1047
11/17/15 5:15:23.243 PM Scrivener[2495]: 5 CarbonCore 0x9acc46a5 Gestalt + 154
11/17/15 5:15:23.243 PM Scrivener[2495]: 6 Scrivener 0x002ea9f0 Scrivener + 3054064
11/17/15 5:15:30.653 PM Scrivener[2495]: [Accounts] Failed to update account with identifier *(removed), error: Error Domain=ABAddressBookErrorDomain Code=1002 “(null)”
11/17/15 5:15:30.691 PM Scrivener[2495]: [Accounts] Failed to update account with identifier *(removed), error: Error Domain=ABAddressBookErrorDomain Code=1002 “(null)”
11/17/15 5:15:30.838 PM Scrivener[2495]: [Accounts] Failed to update account with identifier *(removed), error: Error Domain=ABAddressBookErrorDomain Code=1002 “(null)”
11/17/15 5:15:40.891 PM Scrivener[2495]: CoreAnimation: Warning! CAImageQueueSetOwner() is deprecated and does nothing. Please stop calling this method.
11/17/15 5:15:40.920 PM Scrivener[2495]: CoreAnimation: Warning! CAImageQueueSetOwner() is deprecated and does nothing. Please stop calling this method.

I removed the IDs, although it probably doesn’t matter (but I am not sure)

Most of that is just routine Apple complaining about 32-bit framework usage. How dare we support people who have systems older than a couple of years, eh? :wink: The AddressBook stuff is the main anomaly, sounds like you already fixed that up though.