dump the contents of the 'Interim Note-Changes' file ?

[seanjensengrey]

I have had some drop box syncs that have done horrible things

120K    Interim Note-Changes
1.4M    Interim Note-Changes (grokkos's conflicted copy 2011-06-22)
300K    Interim Note-Changes (grokkos's conflicted copy 2011-07-05)
264K    Interim Note-Changes (right's conflicted copy 2011-07-11)
156K    Interim Note-Changes (right's conflicted copy 2011-07-20)
2.2M    total

is there a way to dump the contents of the ''Interim Note-Changes'' file? Could this be made to pure text with say a ^a separator ? The WAL only gets flushed on a clean exit of NV ? What if someone never exits NV the Interm Note-Changes file will just keep growing and growing?

I stopped syncing NV at all. I am maintaing separate but not equal instances at this point.

[seanjensengrey]

I copied the 'Interm Note-Changes' out to separate folders, then pointed NV at it and converted the notes to plain text for each one. Recovered a total of 218 notes.

[elasticthreads]

Can you be more specific about your use when this happens? Do you have NV
open (and syncing off Dropbox) on multiple computers at the same time? Do
you have a Dropbox base iOS/Android text editor (like PlainText, SimpleNote,
Elements) running at the same time. Are you also using SimpleNote sync?

These kinds of conflicts usually happen when you have a feedback loop caused
by different apps all syncing off the same database at the same time.

On Mon, Sep 5, 2011 at 4:20 PM, seanjensengrey <
reply@reply.github.com>wrote:

I have had some drop box syncs that have done horrible things

120K    Interim Note-Changes
1.4M    Interim Note-Changes (grokkos's conflicted copy 2011-06-22)
300K    Interim Note-Changes (grokkos's conflicted copy 2011-07-05)
264K    Interim Note-Changes (right's conflicted copy 2011-07-11)
156K    Interim Note-Changes (right's conflicted copy 2011-07-20)
2.2M    total

is there a way to dump the contents of the ''Interim Note-Changes'' file?
Could this be made to pure text with say a ^a separator ? The WAL only gets
flushed on a clean exit of NV ? What if someone never exits NV the Interm
Note-Changes file will just keep growing and growing?

I stopped syncing NV at all. I am maintaing separate but not equal
instances at this point.

Reply to this email directly or view it on GitHub:
#269

[seanjensengrey]

I had at one time in the past 3 computers syncing the same Notational Velocity instance. I am no longer doing that. I only ever edited the notes via NV. Other apps never intentionally touched the notes files (which were stored plain text or at least should have been).

I was the only one editing each one at any one time, but it still managed to get confused. It seems to me that the biggest flaw in the way NV batches up the Interim Note-Changes and then commits them on app close is that the Interim file can get very very large and each Notational Velocity instance will have its own Interim file that is never properly synced.

The way

Interm Notes-Changes and
Notes & Settings

work seem a little borked. Sqlite would probably be a better choice.

As I mentioned above, I was able to extract the notes by copying the Interim Note-Changes files to their own directories and opening each one with NV and converting to plain text and then exiting NV.

[elasticthreads]

Thanks for the follow up. Please do, if you get the chance, answer the
questions I asked originally:

1. Are you using Dropbox or SimpleNote sync or both (if so, you should pick
   one or the other)?
2. When you say you have 3 computers syncing the same NV database do you
   mean that when these confliction files appear you have NV actively open and
   running on 2 or 3 of the macs at the same time? (I'm not saying you
   shouldn't do this, but its useful to know what's going on when this bug
   happens).

On Tue, Sep 6, 2011 at 6:29 PM, seanjensengrey <
reply@reply.github.com>wrote:

I had at one time in the past 3 computers syncing the same Notational
Velocity instance. I am no longer doing that. I only ever edited the notes
via NV. Other apps never intentionally touched the notes files (which were
stored plain text or at least should have been).

I was the only one editing each one at any one time, but it still managed
to get confused. It seems to me that the biggest flaw in the way NV batches
up the Interim Note-Changes and then commits them on app close is that the
Interim file can get very very large and each Notational Velocity instance
will have its own Interim file that is never properly synced.

The way

Interm Notes-Changes and
Notes & Settings

work seem a little borked. Sqlite would probably be a better choice.

Reply to this email directly or view it on GitHub:
#269 (comment)

[seanjensengrey]

1. Was using DropBox and only dropbox.

2. I wouldn't see the conflict files, I just noticed the conflicts and I haven't been syncing NV via DropBox or any other service for 3 weeks. I would see a weird 'deleted files' dialog after restarting NV, see my previous bug Drop Box - NV occasionally claims certain files are missing #252

[curby]

Hi, I'm posting here due to relevance but arguably there could be a new issue created. My concern isn't that the Interim Changes are stored in a non-plaintext format, but rather that there are conflicts when syncing with Dropbox.

At the moment I'm syncing two NV instances using Dropbox only. One is on OS X Snow Leopard, the other is on OS X Leopard (old, I know).

The issue I see is that I start NV on one computer, and it makes its own Interim Note-Changes file. When I start it on the second computer, I receive a dialog warning me that it can't open Interim Note-Changes, and asking if I'm running another instance of the program. Well I am, but not on the same machine. I forget the specifics of the dialog, but somehow I'm prompted to restart the application, at which time the existing copy of Interim Note-Changes is deleted. Of course, Dropbox on the first computer notices that Interim Note-Changes has been replaced with a new copy, and so something like

Interim Note-Changes (First Computer's conflicted copy 2011-11-03)

is created. Please fix this conflict issue!