ZIP for syncing?

I wish a future version of Scrivener would be able to sync on many services.

For example, I use Resilio Sync, which is really hardy and secure. However, it doesn’t understand packages, so it doesn’t work with Scrivener project files.

I’ve noticed that several other apps use a file format that is zip or rar-compressed, making it easier to work with sync platforms. The apps unzip the file package locally as needed, and rezip the package to the sync volume to save changes.

Would it be possible to adopt such a project strategy in a future version of Scrivener to make syncing more robust?

1 Like

Are you having trouble with Dropbox syncing not being robust? If so, what are the symptoms?

You know that you can use Dropbox exclusively for Scrivener–as it is designed to work, and use Resilio for everything else. Unless you have a huge document should be able to fit into the “free” Dropbox allocation. I have about a dozen largish documents in my Dropbox sync location.

1 Like

All

Packages sync as folders, even in Dropbox. Recognizing packages is not a requirement. Dropbox is the only service supported for sync to iOS Scrivener, but that’s only if you’re dealing with iOS.

If not, Scrivener has extra error checking for Dropbox on other platforms, but you can use other services if you:

  • keep other backups
  • recognize problems right away
  • know what to do if you see one
  • that is, know how to revert to a backup

The same cautions apply to Dropbox.

2 Likes

Thanks for the reply, I mis-posted.

What I meant to say was that because sync platforms like Resilio Sync do not understand packages, they can’t be used with Scrivener for iOS. Scrivener iOS doesn’t see a project file, it sees a folder instead.

Do you know a way to get Scrivener iOS to load a proejct file that has been converted into a folder?

This has been raised previously and addressed by the developers. In short, don’t expect this to happen any time soon.

  1. Scrivener on the Mac and PC have no tie-in to a sync engine; as far as they know, they’re simply writing to the filesystem – and then your sync engine(s) are also reading/writing to that same place in the filesystem and uploading/downloading with the cloud servers. In contrast, Scrivener on iOS uses the Dropbox SDK so that it can directly scan, download, and upload the various components of a Scrivener project directly from the Dropbox cloud servers – so Scrivener on iOS always knows when a cloud-enabled file I/O event is going to happen and can do the correct things. (Note that only the Dropbox SDK, last I knew, provided the necessary level of granularity in the various API calls for Scrivener on iOS to be able to do this properly.)

  2. Compressed file formats start causing more problems the larger the project size gets, especially when the time comes to save items back. In short, writing changes back to the project means the entire project has to be re-compressed. Scrivener projects can get VERY large – long-time users can and do have projects that are dozens of GB in size, in part because of their Research content (which is one of the attractive features that Scrivener offers) – and because of that, Scrivener only makes changes to the minimal numbers of files necessary (and by default, saves those changes after 2 seconds of inactivity.) Adding the compression to the project format could dramatically slow down saves, lengthen the interval between saves, and generally interfere with the features of Scrivener that have historically been some of its biggest draws.

1 Like

If you use Resilio Sync to synchronize a Scrivener project between two Macs, or between a Mac and a PCC, does it not sync the project at all (or not sync it with fidelity)? If so, then that’s a serious flaw with its Mac implementation.

Other sync engines can’t be used directly with Scrivener for iOS because Scrivener for iOS uses the Dropbox API directly to work around iOS sandboxing and the lack of a directly shared filesystem. The Dropbox client functionality is directly embedded into the Scrivener for iOS app, instead of relying on a separate Dropbox client the way MacOS/Windows do it.

However, you can use another sync engine to get your data to your iOS devices using their iOS apps – and then use the Files app to manually move the project files between your sync app’s file space and Scrivener’s file space. I would be surprised if Resilio Sync did not let you operate in this fashion.

1 Like

I not sure if I’m understanding the situation but I sometimes use a sync service which sees an extracted Scrivener ZIP file as a folder.

From a manual (not automatic) perspective, to get into iOS Scrivener I copy the ZIP file to the generic “On My iPad” Files app space, then extract there which produces the desired Scrivener package file, then move it to Scrivener’s space.

There’s third party file managers that could be used as well as the extraction location instead of Apple’s Files app. At least there used to be. In the past I’ve used the third party app, File app.

That’s because a Scrivener project is a folder, with subfolders and potentially hundreds of component files. It is essential that whatever service you use transfers the entire folder and all of its components. One way to ensure that this happens is to compress the project into a ZIP archive.

That’s not the reason at all. The reason is that iOS Scrivener uses the Dropbox API to do the synchronization.

1 Like

I know. Thank you, nonetheless.

I wasn’t sure of @popcornflix 's (and Resilio’s) situation and whether s/he had tried to extract the archive outside of Resilio’s space. Could be that that had been tried/used and only a fully automatic solution was in mind.