Well you have a point here, having one cache .db for all notebooks will certainly have its shortcomings. But we are already discussing technical details. Let's get back to this discussion when this issue gets to the top of the implementation list, because when it does, some of the circumstances may change and we'll need to discuss it again anyway.

CN would need to be changed, and drastically:

1) it would need to monitor when this backup file is changed by Dropbox

2) it would need to know that it was indeed changed by Dropbox and not by itself

3) since the backup is a lengthy background process, the probability of conficts increases

4) on conflicts, Dropbox renames the conflicted file and CN would need to do something about it

5) when Dropbox updates the backup file, CN would need to read the changes back into the main file, which is also a new functionality that needs to be implemented.

In short, this creates much more problems than it solves, sorry)

You have a point there with the ability to rebuild as a criterion. However, I still think that data which can change on read operations has no place in the db file itself. Anyone who got the "do you want to save changes?" prompt from Excel when he in fact hasn't changed anything would agree here.

Yes, it will be restarted when CintaNotes releases the file lock - which happens after 30 seconds of inactivity.

I guess this can be done via introducing an extra database, which would serve as a container of cached data and statistics. Actually some of cached data could be moved there out of current .db files (the NoteCache and TagCache tables, for example), so the size of the .db files could be reduced. The cache database could be stored e.g. in cintanotes\cache\{notebook-uid}.cache.db.

Also viewstate settings could be moved there from the settings file.

> if only reading is all you did, there is no need for syncing, right

Yes. But Dropbox will start syncing, because somewhere in the DB the "relevance" counter has been increased. This can lead to conflicts.

>but how many users will be affected? Could the feature be optional?

Pretty much everyone who uses some kind of file-based syncing. It is not only Dropbox, but also SugarSync, SpiderOak and a bunch of other services. Introducing another option - this is a road to bloatware and complexware which I want to avoid at all costs.

Thanks for the suggestion, Thomas!

I think it is a useful thing to have. The only problem that I see is that just reading the DB will change the db file - very bad for Dropbox syncing and R/O files support. We'll probably have to store this data somewhere else.