Google sheets and failed Dropbox sync

Hi Scrivener Folks,
Yesterday I imported a google sheet into a Scrivener project, one where I can read and interact with it both through Scrivener and Google sheets, and it updates on both. But today I found that it hadn’t synced with Dropbox like it usually does on my iPad. When I went to DB to investigate, there was a message saying “File missing extension: Missing or incorrect extension. Try adding xml to your filename so you can view it on all devices.” Seems like a recipe for disaster in Scrivener-land. Any thoughts or experience with this kind of thing? FWIW, I imported the Sheet into the research section of the binder.

For a start I would tap the Edit button on the main project screen, select the project and share it, AirDropping to the Mac or PC, or via some other method of transfer. That will avoid any sync code and send a simple .zip file.

Now at least it isn’t stuck on the device, for one, but secondly it is easier to examine the contents of a project (I don’t think it’s even possible to examine a package on iOS and the Dropbox UI won’t let you either). If you need any help with that let me know, but it should be a pretty easy task of going into the Files/Data subfolder of the project package and sorting the folders by creation date, since it will be one of the more recent things added.

What you should see, in one of those randomly numbered folders, is a .webarchive file, though why Dropbox would say it should be XML, I don’t know. Where did you get that message from by the way? The Dropbox client on iOS won’t be aware of whatever is saved inside Scrivener’s storage area. It only knows what is on the server.

1 Like

Thanks! To start with your last question, I signed into the Dropbox app, searched the project name, and saw an error triangle next to it—the message came up that way.

I’m not clear what’s accomplished by sharing through airdrop, then dealing with that recent package file. Will this fix the problem or is this just a one-time solution for this one backup and I will encounter it each time I work in the spreadsheet and want to see it on another device.


Okay, interesting, so itself was having troubles. I found the error message a bit odd, as I can’t think of why it would need an extension to sync a file. Extensions are optional on some operating systems, but it’s also strange that anything would end up in Scrivener without one. Could be the error wording itself is a red herring.

As for the rest, we’re tying to get to the bottom of that. iOS is a black box that is very difficult to debug problems on. Getting your project copied to the Mac or PC (since it can’t sync) is a way of taking a closer look at it. But like I say, it also copies your work off the iPad so that it is safe, and not just stored in one place.

Ok thanks. Just to clarify so I do this right: I imported the google sheet and worked with it on my Mac. I also did a ton of other organizational work, moving files, creating new folders etc. That was yesterday. Today I wanted to pick up where I left off, this time on my iPad. If the iPad hasn’t updated, why am I sharing the project from there to the Mac rather than the other way around? Maybe I’m still not clear about the end result I’m striving for.

And one more thing, is it safe for me to open the project on my iPad anyway without creating an un-synced nightmare? I ask because I watched the Dropbox sync on my iPad, and it hung at 3 files to go, so I’m thinking maybe it synced everything else, but I’m worried I will open another Pandora’s box.

FWIW, I’m backing up my Mac on an external drive—something I do regularly. :slight_smile:


Okay! From the initial message it sounded like the latest version of the project, with the sheet in it, was stranded on the iPad and wouldn’t sync up, hence trying to get that copy off another way.

So yes, if it’s on the Mac instead, then yes, don’t worry about the iPad for now.

In that case, locate your project in Finder, right-click on it, and select “Show Package Contents”. This is where you will find the Files subfolder, and then Data within that, and the numbered subfolders within that. In these folders is where Scrivener stores all your text, and all the files it imports. Set your Finder window to sort by creation date, and start looking through the newest folders, looking for anything called “content” that doesn’t have a file extension (“content.rtf” for example, could be a chapter, or some notes, and “content.webarchive” would be a web page you imported, like the Sheet should be). You might not find anything, because like I say that’s a kind of weird result/error, but if you do find something we can go from there.

Make use of the Spacebar on these content files to preview them. That’s a passive preview so you won’t hurt anything by just looking, and from that you can get an idea of what part of the binder you’re looking at.

By the way, definitely go into Finder preferences, and in the Advanced tab, set it to show all file extensions before doing that. Otherwise everything will appear to have no extension I believe, and just be called “content”.

Thanks, and sorry for any confusion.
Following your steps, I located a couple of things of possible interest.

  1. at the top of the data folder, before all the numbered folders, was a file docs.checksum This would have been when I opened Scrivener on my ipad and said yes to syncing, in the hopes of accessing the work I’d done on my Mac.
  1. Right below that in a numbered folder, from the day before, I found the imported google sheet as content.webarchive — as you said. Hitting the spacebar, the document was empty, and there’s black banner error message at the top that says: “The version of the browser you are using is no longer supported. Please upgrade to a supported browser in blue (I don’t think it’s a link, but I can’t tell viewing it this way) followed by Dismiss, also in blue. At the bottom is a text box that can be closed that says: “The Current window is too small to properly display this sheet. Consider resizing your browser window or adjusting frozen rows or columns.”

I recall filling some parts of the sheet through Scrivener and being pleased that I’d seen it sync up when I checked by going directly to google drive/sheets.


The docs.checksum file is fine. Every project will have one of those, and this is one of the tools that Scrivener uses to check for internal sync inconsistencies. Basically it’s a way of taking everything in this folder and making a magic number out of it. If a single letter changes anywhere in your project, that number changes. So when we open the project, we check to see if the number stored in the file is the same as what is stored everywhere else, and if they don’t match we know the data changed without Scrivener knowing (or maybe there was a crash). It does some rebuilding in that case.

So that shouldn’t be messing up sync, because like I say, every project should have one of those.

Okay with the preview not doing a good job of showing you the sheet, that isn’t too surprising. What is happening here is actually a bit of a “glitch”. The .webarchive format is meant for storing offline copies of webpages, which is just about the opposite of what you’re using it for. Sometimes pages like that can work through the Scrivener web viewer, sometimes they don’t, it’s something you can consider a nice convenience if it does, but don’t expect to always work.

But that still doesn’t explain why Dropbox wouldn’t be syncing. I’m thinking maybe some Dropbox troubleshooting is in order. A common step to take is to clear its cache. While ordinarily it works as they describe there, it can sometimes get jammed and cause odd behaviour.

After doing that, if you are still getting the error, then I would try moving the project out of the Dropbox folder entirely and letting it sync the full “deletion”. Once it is done, move it back and see if it fully uploads.

And if that doesn’t work, you might need to get in touch with Dropbox support and see if they can help you make that error message more specific. They might know of log files they can point you to that would say precisely which file is having troubles.

1 Like

Thanks for the explanation. I will clear the cache and contact DB if the problem persists. But first what does letting it sync the full “deletion”. mean?

Just watch the sync status indicator up by the clock and other icons, and wait till it is done.

Hi Amber,
It looks like the issue isn’t with DB, but with Scrivener, since I was able to sync once I removed the Google sheet from my project. I get an error message within Scrivener, which says there’s “the version of browser you are using is no longer supported, Please upgrade to” and there’s a link to Safari, Firefox, and Chrome. (I’ve tried loading using Safari and Firefox but get the same errors. The strange thing is that with the error message floating at the top, I can edit the document from within Scrivener on my Mac, and the edits show up on my google sheet when I go to a browser. I could even add a few characters from my iPad that appeared both on my browser and on my Mac but it wasn’t smooth. After that attempt to edit on the iPad, it stopped syncing with Dropbox again.
Basically, I just want to import a spreadsheet into Scrivener, work on it there (either on my Mac or iPad), then have the changes reflect on my google sheet.

The error message isn’t coming from Scrivener, but from the web page. This is why it is vague about what you’re using to look at the page with, and makes a nonsense suggestion to upgrade to a separate web browser. It doesn’t know you’re looking at it through your operating system’s simple web viewer, running inside of another program.

Like I say, in theory none of this should work at all, and contradict the design of the technology being used to archive webpages offline. That it works at all is a bit of a fluke, and so if you can get it to work, all right, but I wouldn’t depend on it or try too hard to make it work if it doesn’t.

I can’t explain why Dropbox would struggle with it, as the file itself shouldn’t even be changing, something is still a bit odd there, but perhaps somehow it is changing even though that shouldn’t happen. Needless to say many people store .webarchive files and use Dropbox, so that isn’t a universal problem, whatever is going on.

But it’s hard for me to really offer much advice since we’re talking about how Apple’s web page archival format being displayed on two of Apple’s operating systems at our request, interact with another system we don’t control, Dropbox. Scrivener is just playing in the middle here for two things not working well together (when they shouldn’t “work” like you describe at all).

1 Like

Ok, thanks. This has been a long haul, and appreciate you sticking with me to figure out that there’s not really a fix. Do you think it would sync better and I could work on it on both devices if I was using Excel or Numbers instead of Google Sheets? That would eliminate the dynamic web piece. Just curious as to whether I should even try. :slight_smile: Thanks again!

That’s what I would do, personally: put a spreadsheet file into the project, and then work on it using the original spreadsheet software. There is a button in the footer bar that can be used to load a resource in its default editor (as well as a keyboard shortcut, in Navigate ▸ Open ▸ in External Editor). Scrivener works quite well as a data hub for files like this, and it is designed for it. It hosts the original file, so changes you make are saved right back into the project’s copy, and thus available to other devices. Naturally that won’t work on iOS though, where software is not allowed to cooperate together like that. I don’t know if that’s deal breaker for you or not. For me it is not, I only use iOS to take quick notes.

To perhaps clear up one point, when you imported a Google web page into the project, it wasn’t actually importing the spreadsheet, rather probably only the bare minimum necessary to load the rest of the Sheets web app into the window, and then in turn your spreadsheet data. So that is in effect identical to using your web browser, only in a much more limited fashion that only kind of works. The only advantage is that it can be in a split view, rather than a browser window alongside Scrivener.