Does Dropbox sync smartly notebook files? [duplicate]

Question

It is said that Dropbox employs a Delta Sync technology where only the modified part of a file is updated through the internet. I was just wondering if it holds for notebook files.

I sometimes work with nb files as large as 100MB and modify only a little portion each time. From the time consumption in syncing, I vaguely have the impression that it's not just the modified part being transferred, if not the whole file. Is this true and any possible cause related to Mathematica?

Suggested in the comments, another question addesses the issue of version control mainly in terms of a developer team and mentions large metadata. My question is even simpler and more direct. Here, there's no explicit need of version merge or bookkeeping and only one developer's latest version is saved.

Put it more clearly, if I modify only one of five totally separate sections in a notebook, why can it not just sync the modified section? Their metadata parts should also be independent (locally modified at the level of separate sections)?

Answer 1

Preface: I still believe that all necessary answers to this question can be found in "Are there suitable versioning systems for Mathematica notebooks?". I encourage you to read all answers there as they give a pretty good picture of what can be done. My answer here is merely for a detailed explanation.

---

As already stated in my comment, syncing only the changed sections will not work in Mathematica's default setup. Let me elaborate on this subject and show you how you probably can make it work in your specific case.

As a test-case, I have created a notebook that contains nothing more than

In[1]:= 1 + 1

Out[1]= 2

I have made the source of this notebook available here. Please have a look and let me explain, why Mathematica notebooks change so drastically even when you only make small changes.

1. At the beginning of the file and after the usual header information, notebooks store internal cache information. This section contains the positions of the various parts of this notebook. So, for instance, the NotebookOptions start at character 941 in the file. It is clear that changing only a very small thing in the notebook, changes these lines as well.
2. Each cell has a CellChangeTime and an ExpressionUUID attached to it. In addition to the obvious changes you make, Mathematica will change these values as well.
3. I already mentioned the NotebookOptions which are the options you find starting at line 33. These contain information about the notebook size, notebook position, and front-end version. As soon as you move or resize the notebook and save again, these settings change. If you, like I do, use Mac and Linux, the front end version will change as well.
4. The FileOuline at the very end changes too, completely, even on the smallest edit of your notebook. The reason is that this outline contains the character positions of each cell. As soon as you add/delete something from a notebook, all of these values change on Save.

This is the reason, why there are so many changes in a notebook-file even when you make a small edit. So when I change my one cell from 1+1 to 1+2 end evaluate it, the notebook will actually contain the following changed lines

Red/green portions indicate changes.

What Mathematica does allow is to turn both the file-outline and the tracking of CellChangeTimes off. You can use Preferences -> Advanced -> Option Inspector to change these settings.

1. Editing Options -> TrackCellChangeTime -> False
2. Notebook Options -> PrivateNotebookOptions -> FileOutlineCache -> False

So if you like, go ahead and try this. With these new settings, the changes will be local to 3 places: The changed input cell, the newly created output cell and probably window position of the notebook. Note that the size of the notebook went down because it really contains only the notebook expression:

A few remarks

1. I'm sure Wolfram has good reasons for the cache and the file-outline; e.g. speed or corruption-protection. So be aware of that and acknowledge that you turned it off on purpose.
2. I guess I don't have to mention that making a tiny change in a plot command and recreating a graphic might lead to large changes in the notebook as the created graphics primitives are totally different (and they are large).

My final remark goes beyond your question. From what I have explained, it should now be completely clear why notebooks are evil when working with a concurrent versions system like Git. Say you have 10 developers, you must ensure that each and everyone has turned off caching. Otherwise, each update to a file might contain switching back and forth between having an outline or not.

In addition, different developers have different systems and will definitely move the notebook on their screen. So on each new commit of a notebook, at least the notebook-options at the bottom will change. For one, this makes merging and diffing a nightmare. But more importantly, can you guess what happens when I move the notebook to my second screen that has an x-pixel-position of e.g. 4100 and then poor Szabolcs tries to open it on his laptop? I'm not sure if this is still an issue, but I definitely had this problem when notebooks I saved on Linux, were placed off the screen on a different system.