I’ve used the older version of Scrivener for years, saving to dropbox and working on a project on one of 2 macs. Since upgrading to 3.3.1 I suddenly can’t do that. The file opens from dropbox on the mac it was created on, but, on the second mac i just upgraded, I get this: “The project at “/XXXX.scriv” seems to be of an older format, but no binder.scrivproj file could be found inside it. It may be missing or corrupt, possibly because of a problem with the device on which it is stored, or because of a synchronisation problem.Try ctrl-clicking on the project in the Finder and selecting “Show Package Contents”, then look for a file entitled ‘binder.scrivproj’. Ensure it has not been renamed by a backup routine. If it does not exist, try restoring from a backup.”
the versions are the same, and when I try to go directly to dropbox to download the saved project, it’s in folders and the file with the same name will download but not open (message telling me its missing files).
I expect that on the one machine (you just upgraded) where things are not working, Dropbox is set to make your db files remote only meaning db has literally removed your project files from your harddrive and left (fooler) placeholders in their stead — with the idea that your files will be served back to you on demand. This kind of set up does not work with Scriv projects. You need to find the Dropbox/applications/Scrivener folder on that machine and tell Dropbox that everything in that folder is to stay put. The files will still sync with dropbox as always.
Thank you, @gr! yes! this was the issue–when I corrected by left clicking on the project name in the second machine and choosing off-line copy, everything synced up.
I believe Dropbox have explained their software, their chosen “default” to be “online”, and have documented in their FAQ how to set to “offline”. They also have put control of this to the user in their app’s menus. A little bit of curiosity by users on the Dropbox settings would go a along way, I think–but I realise few do that exploration for reasons which often make little sense to me. Pity.
What’s missing is some Scrivener users realising that Scrivener needs all files in the macOS “package” to be “offline”.
And then when Scrivener doesn’t work, it is “of course”, Scrivener’s bug. Not.
I agree it would be great and nice if Scrivener documented this fully, informed via a “newsletter” (as suggested by @drmajorbob), or whatever else might be useful. Won’t catch everyone of course, but better than simply putting entire onus on Dropbox. IMHO.
Even better, Scrivener app perhaps could be modified to check the Dropbox setting, or look at the Scrivener project files to detect that not all files are present on the local machine – then inform user.
The problem here is that it is completely normal for a Scrivener Binder item to exist with no associated text file, so such a condition is not inherently “erroneous.”
Yes, I see that as one of the situations to be included in the algorithm for checking status of “online” and “offline files”.
But if the binder does have files, and those files are “missing” or are in some state set by macOS to indicate “online”, then there is a “possibility” of something erroneous that could be notified to user? Or maybe there is something in the Dropbox API can could be used?
I of course don’t have access to Scrivener’s source code, and I’m years away from doing any serious coding like this, but just seems to me that if Scrivener choses to “fail” on online Dropbox files, the error checking “on fail” in Scrivener could be programmed to give a suggestion to the user as to what might be wrong along with a pointer to something in Dropbox to check.
Sorry to be snarky, but this change in Dropbox’s default settings dates back to Monterey, which is nearly two years old. At some point we really do have to assume that people are capable of using search engines and reading documentation.
I’m ok with “snarke”. I sometimes fall into that too!
Evidence here is that some people aren’t capable. Or the symptom is not indicative of the cause–or something. Is it enough evidence to warrant a software change? I guess not.
The thing is that Scrivener doesn’t fail unless the missing component is something critical, like the .scrivx file. For a Binder item to have no content is not an error condition, and Scrivener will happily present an Editor screen.
Remember that – by design – Scrivener only attempts to load a Binder item if you navigate to it and try to open it. The integrity check that Scrivener does when it opens a project compares the .scrivx file to the UUIDs in the project’s file structure, but it doesn’t look inside each of those items to check the contents. Nor should it, as you can easily understand when you consider the performance implications of trying to verify thousands of files spanning hundreds of megabytes when the user was just trying to make a note about a character’s eye color.
And finally, remember that Scrivener on the Mac (or PC) does not talk to Dropbox directly. It talks to the file system. Which may or may not itself know the status of the file, and might not expose that information to application software in any case.
Documentation and spreading the word are two different things. Information systems are of very little use to users who don’t know what to search for and aren’t in the habit of searching databases in the first place.
Well, you suggested a newsletter. Which is not a terrible suggestion, but again this is a two year old change. If we’d included it in a newsletter or blog post when it first happened, people now would still be relying on a search engine to find it.
As for what to search for, searching for the text of the error message itself is not a terrible idea. In fact, if you search Google (not just our site) for the error message, our article on the subject is the first link.