Syncing the file structure of the binder

(Hopefully this is no old issue, that I bring on the table. I couldn’t find something about it.)

Syncing is very useful for backup and to write and read on an iphone or ipad.
There is only on thing, that is bothering me:

  • I have a hierarchical folder structure in the draft folder (a folder for each chapter and sometimes for some under-chapter), and in each are several text files.
  • When I sync, Scrivener put all the text files from the different folders in my draft folder together in one draft folder in the external folder (Many “folders” for one sentence)
  • Its confusing to find what text is for what chapter

My wish is, that there would be an option in the sync options, that Scrivener is building folders in the external folder like in my draft folder (the same for the other folders in the binder).

I love Scrivener.


Hi Karl,

Thanks for the kind words. Unfortunately there’s no really satisfactory way of doing anything like this, because a file system structure is very different to an arbitrary structure such as you find in the binder, even though they are superficially very similar. In particular:

  1. Any file in Scrivener can be a container - so a text file can act as a container to other documents. And folders can have text associated with them. To sync such files with a folder system, two files would need exporting where only one exists in Scrivener - the text and a folder. If the user moves these to different places, re-syncing would have to try to work out where both are and how they would become one again in the binder.

  2. File systems cannot be sorted arbitrarily. In Scrivener, you can drag any file anywhere. In the Finder, everything is sorted by title, date, type or whatever. Although numbers could be attached to the beginning of each file, to sort anything in the Finder you would then have to renumber everything manually.

In short, it would be difficult to manage and it would be way too easy to destroy your entire file structure. Sync just isn’t meant for this sort of thing - it is solely for getting text out there.

I don’t rule out rethinking this some more in the future, but it certainly won’t be in the short-term, sorry. I hope this explanation makes some sense though.

Thanks again and all the best,

Hi Keith,

thanks for the reply. I though some time about this. As a USER, I am not really in the details of how to program something. The numbering works well right now, when opening a file mobile from dropbox.

Maybe the best solution would be this: a Scrivener iPad-App :slight_smile: Yippieh yeah !!!


With all due respect to the work that has already been put into syncing (which I am finding so wonderful with PlainText on iPhone), I do think preserving the file structure would be handy.

To your points, Keith:

I think it is a perfectly reasonable compromise to warn the user against moving existing files, with the consequence that their structure or relationship to the Scrivener project may be lost in the process. You’ve already made it clear not to edit document titles outside of Scrivener, which is just fine. Perhaps, upon syncing back to Scrivener, if you find that any files have been moved, simply refuse to sync or offer the user a clear warning. I think it’s safe to assume that any user syncing back and forth is fairly comfortable with the process and the considerations (risks) involved.

Text files as containers would indeed have more that one actual file associated with them, but you’ve already dealt with that in the Scrivener document package itself (pairing 17.rtf and 17_synopsis.txt). Admittedly, that’s invisible to the user. But again, those who are syncing might be a bit more aware of the workings of transferring files back and forth. The top of each synced text container (or folder with text) could have a file called “00 =Text= -17-.txt”, or some such. Folders without text content simply wouldn’t have this file.

Lastly, regarding sorting arbitrarily, you’ve already solved that one with numbered file names. There needn’t be a more elegant solution than that.

If it’s worth considering for a future version, great. If not, I already have enough functionality to make the current workflow a pleasure to work with.


Thanks for your feedback Alan, much appreciated. I did spend a lot of time thinking about it, and the problems really overcame the advantages, especially in terms of how much chaos it could cause (and refusing to sync would get us grief). My experience so far has been that all sorts of users use the sync feature, many of them not really aware of how it works, so I don’t want to risk further confusion. However, I rule nothing out for the future as Scrivener is constantly evolving.

All the best,

I’m new to Scrivener, and I love it!

This feature was something that I did miss, though. My initial thought was rather than sync the binder hierarchy to nested folders (which would have all the problems that Keith described), you could sync the entire hierarchy to an OPML file (with the text contents in the “notes” field of the outline elements). That way, you could go back and forth between Scrivener and OmniOutliner as you were editing. The real benefit would come once CarbonFin Outliner or OmniOutliner for iPad develops Dropbox syncing, which will probably still be a while. But it would be nice to sync to a single file that kept all the structure (and allowed editing to it) instead of a flat folder of hundreds of text files.

It obviously would run into the same OPML parsing issues described here:

So I imagine it’s not feasible. But I thought I would throw it out there as a possible alternative.

Thanks for the awesome work!