Binder emptied entirely when moved from Dropbox folder

Scrivener Scrivener for macOS
,
1

I have been working with Macs for more than three decades (long before OS X), and with Scrivener since the V.1 days. I have a history of coding, and wrote an intro-to-programming book published by Osborne. Please bear these facts in mind when composing a reply. I am not a novice user of any of this software, by any means or stretch of the idea.

Here’s what’s happening. In brief, moving projects from Dropbox to an iCloud drive folder appears to result in deletion of all files within that project, leaving me with an empty binder.

I’ve been using Dropbox sync since before Scrivener came out on iOS, and I like using it with Scrivener, for the predictable reason. The experience has (for the most part) been trouble free.

When I’ve completed a project, I move it from the Dropbox folder to a finished-work folder that is not synced by DB, but is synced in iCloud. I have been doing this for years, and experienced no difficulties.

With the last two Scrivener projects I’ve created and completed, both of them begun in early October, what I have found is that after I’ve moved them out of Dropbox, the binders are emptied.

This does not happen immediately. I’m not certain when it happens. When I return to those projects in the completed-work folder, I find they’re KB in size, not MB, and when I open them, I’m presented with a fresh, empty binder.

There are no files within it anywhere — text, images, or anything else — and the inner structure I’ve given the projects (subfolders, etc.) is gone. Also gone are the settings for the general binder presentation; I’m quite literally presented with a brand-new, totally empty binder, without even an initial text file in it. Everything contained within the project has been deleted.

In both cases, I’ve had to restore from Scrivener’s backup. Doing so results in the restoration of the project, and subsequently, they remain intact. Nothing later vanishes from the binders under mysterious circumstances.

This is novel behavior that has never manifested in my entire experience using DB to sync Scrivener projects between Mac and iOS.

Surmise: There appears to be some sort of interaction going on between iCloud and Dropbox, and I’m beginning to wonder if it’s being caused by my DB sync folder being treated as an iCloud folder, despite the fact that it is located in /users/warren/Library/CloudStorage, which is not a folder that I have selected for (or should be part of) iCloud drive sync — and there is a conflict between iCloud and DB that’s causing them to disagree on what has been synced, moved, or deleted.

IOW, this feels like something that Apple and DB need to hash out between them.

System specs:

  • MacBook Air (2020, M1 Apple silicon), 16 GB RAM, 512 GB SSD, 235 GB available, macOS Sonoma 14.6.1

  • iCloud drive has 200 GB, 55 GB available

  • Dropbox storage has 9.75 GB, 8 GB available

  • iPad is 10th generation, iPadOS 18.0.1, 256 GB, 150 GB available

  • Most current Scrivener on both iOS and macOS

  • Dropbox desktop client version 209.4.3661

As an interim fix, I think what I’ll begin doing is a two-step move of my finished files.

  1. Move them from DB sync folder to a non-iCloud folder (i.e., not my “Documents” or “Desktop” folder).
  2. Let the finished projects sit in that folder for, say, 24 hours.
  3. Move the finished projects into the completed folder in my iCloud sync “Documents” folder.

The rationale is that if there is interaction between iCloud and DB, whatever flags have been set by whichever software for wholesale file deletion will (ideally) have been cleared after 24 hours’ time, and neither DB nor iCloud will be hell-bent on purging something it shouldn’t be touching at all.

This may be related to a report I posted a few days ago regarding binder.autosave and binder.backup file sync never finishing. Both sets of problems (that one, and this one) have begun appearing only since the first of October, and I’m now dubious as to my original suspicion, that the previously reported issue was somehow due to selecting fingerprint ID security on Scrivener for iPad.

2

As noted here, DB appears to be causing another misbehavior on macOS, with a delay in syncing certain Scrivener files. I was able to confirm that a few minutes ago, and the version of DB I’m running on desktop was updated on Oct. 4, and I first started noticing both sets of problems in early October.

3

I’d recommend contacting Dropbox support.

One potential cause of this is that all or part of the project was stored exclusively on the Dropbox server, and was not downloaded to the local system when the project was moved. If iCloud whisked it away to their server before Dropbox finished the download – which should have been triggered by moving the project – an empty project could be the result.

We recommend configuring Scrivener projects to be “available offline,” regardless of what service is being used.

We also recommend considering cloud-related risks when deciding your backup strategy. So, for instance, don’t store a project and all of its backups with the same cloud service.

For Mac users in particular, we strongly recommend using an external drive as a Time Machine volume.

2 Likes
4

Not quite certain of the relevance. In 40+ yrs in IT and semiconductors, including at Apple, some of the most monumental stuff-ups were by the most experienced. but… here goes.

I carried out several quick tests.

An existing project and a new project, both in the local folder for Dropbox. Dragged the entire .scriv from the Dropbox folder to a new folder in the local iCloud folder.

Left them for a while to ensure all syncs completed.

Both projects have all their contents and open correctly in Scrivener.

Even tried editing a project in iOS Scrivener, waiting for it to sync, then dragging it from the Dropbox folder to iCloud, waiting for all syncs to complete and it’s all there. I’ve also opened iCloud in a browser and checked the file that’s synced up. Everything is there (Not opening it with Scrivener, because that’s not supported)

I’m assuming you have both Dropbox and iCloud set to the equivalents of ‘offline mode’?

The only significant difference is Sequoia, but I’ve not seen any changes in the way Dropbox or iCloud work for me since the update.

Sequoia 15.01
MBP 14" M2 Max, 32GB 2 TB
iPad Pro M1 iPadOS 18.0.1 1TB
Dropbox 2GB free of 8.35GB - 209.4.3661
iCloud+ 40GB free of 200GB

3 Likes
5

The point of the intro graf was to forestall fog-the-mirror level questions on the order of, “Are you sure your computer is switched on and-or connected to the internet?”

I do indeed have local storage set for everything. And it doesn’t seem to make any difference. Some items get synced whenever DB jolly well decides to sync them, it seems.

Considering you’re reporting no such difficulties, I’d say this is a Sonoma-plus-Dropbox bug.

1 Like
6

I didn’t have any issues with Sonoma prior to the release of Sequoia and haven’t seen reports of this issue here, or on any of the Scrivener groups I’m on, which makes one wonder about potential system or network issues specific to your case.

I did consider asking if you had turned the system on, but decided that was just too obvious.

1 Like
7

Thing is, I’ve been using Scrivener for well over a decade, and Scrivener/iOS/Dropbox since Scrivener for iOS was released, and I only saw this at the beginning of October, which was when the Dropbox client was updated.

So if this was introduced by that update, the odds are pretty good you wouldn’t have seen it, if you updated to Sequoia before Oct. 4.

The hardest part for me is printing, because the computer never sees the printer, no matter how carefully I point its camera at it.

8

Pretty certain I was still running Sequoia on a second volume at that point and using Scrivener day to day on the Sonoma one.

9

Interesting. Was the other machine Intel, or Apple Silicon?

10

Apple Silicon - Both OSs running on the same machine on a second volume and using boot selection.

11

Curiouser and curiouser.

There is no .dropbox.cache folder in the DB folder, but only this evening I got a “new” notification telling me my passcode was [digit string], and I could finish setting up my new device, which could only be the G10 iPad I got about a month ago.

Well gosh, guys, thanks for telling me on the day of…