To expand on what Katherine said, even though a Word file is actually a ZIP archive of an entire folder/file structure, it does not live on disk as a folder and file structure (the sole exception being in the user’s configured TEMP directory, for transient periods of time). Every time you save it, all of the files that make up that Word document get zipped back into a single archive file that is a faithful point-in-time representation of the document as it was when it was saved, even though the internal components are pieces with a defined schema and links and metadata. That single file is then written to the hard drive and if you sync it with iCloud, Google, OneDrive, or any other sync engine, it is a single file that is completely independent and self-consistent, because Word is working with the copy in memory and the TEMP directory, not with the pristine saved copy it just wrote to disk. It only uses the .DOCX file when you open the file or when you save the file (or otherwise write to it).
A file package, however, from what I understand is not the same way. To your sync engine client looking at the file system, it’s a folder with a bunch of files and sub-folders, linked in the very specific ways Katherine mentions. Scrivener and the Finder treat it like a single file – albeit with the caveats you mention about being able to force your way into the folder structure – but it is at no time a single file that gets unpackaged or packaged up. And the sync engine clients scouring the file system do not see it as a single package – they see it as a folder full of tasty bits and bobs.
And the problem comes in with how they track and sync changes to those tasty bits and bobs.
Say that the sync engine is trying to save bandwidth and be clever. If you’ve just updated multiple files multiple times since the last sync, your sync engine has a choice on how it handles those changes:
-
Faithfully preserve the sequence of writes/changes across the entire portion of the file system the engine is monitoring, and sync those changes in the order they happened on your file system. This is slow and possibly transmits more data than necessary – what if some of those changes were you writing new data into a document, saving it, then reverting those changes and saving back? However, it most faithfully preserves the sequence of changes and is the most “safe” option. It assumes the writes happened the way they did for a reason and doesn’t make any assumptions about file formats or relationships. (This seems to be the way Dropbox works, BTW, from my limited testing and research.)
-
Faithfully preserve the sequence of writes/changes per file, but optimize those so all pending changes to a file happen at the same time before it moves on to the next file. This method will guarantee that your changes to each specific file are preserved, but for a (usually very small) period of time, any files that have relationships to each other (such as those inside a Scrivener package) may not be consistent with each other.
-
Try to optimize, in some fashion, the sequence of writes/changes by removing those that don’t seem to be necessary. If I’ve saved to the same file three times, skip the first two saves and just go to the last version, right? I save time and bandwidth – everybody wins! Unless, of course, those intermediate states track to other changes in other files that now I lose because I assume my files are independent of each other.
Say, for instance, those three saves were renaming the file (because I changed the title)[1], creating a new file with the old name, and adding content into it. By throwing those first two saves away, I’ve introduced corruption. And yes, some sync engines do try to cut corners like this.
The problem gets compounded when you add in multiple clients all trying to push/pull changes at the same time, or the fact that on a Windows system you don’t HAVE a package, you really are dealing with a folder with lots of files and sub-folders, and now you have multiple copies of the Scrivener document open at the same time…all of these levels of complexity add more uncertainty to the mix and are more likely to expose and exercise the flaws in 2) and 3) to fatally corrupt your project.
[1] Yes, I know my example with renaming is no longer how Scrivener does it – UUIDs are good – but the point is there – mess with writes and write order and you can introduce unintended inconsistencies in a non-trivial file system.
