zim-wiki team mailing list archive

[Jaap Karssenberg <jaap.karssenberg@xxxxxxxxx>]

On Wed, May 8, 2013 at 6:02 PM, Mark Hughes (Zim mailing list)
<mark@xxxxxxxxxxxxxx> wrote:
> I've been using Zim on a large complex notebook synched between Windows 7
> and Linux by Dropbox for a couple of months and NO PROBLEMS.
>
> ISSUE 1 - Synch using SpiderOak v5.0
> I'd much prefer to synch using SpiderOak than Dropbox so when they updated
> to v5.0 and claimed to have fixed some of the bugs that were causing
> problems I immediately tried the new SpiderOak. I quickly got some errors
> when renaming a page that was referenced by other pages.
>
> Some of the links don't get updated, and I suspect this is a Zim issue. At
> least, Zim not saying anything about might be an oversight/bug in Zim. At
> least if my guess aobut what happens is corrent. I suspect that during a
> page rename, when updating several links in a page, Zim does several
> read/edit/write/read/edit/write... operations in succession. If so,
> SpiderOak may spot the change, lock the file while uploading it, and so the
> Zim-write fails. Zim reloads, loses the edit, does the next edit/write etc.
>
> Note that I don't get this issue with Dropbox, but I wonder if that is just
> because Dropbox is a bit lazier before acting on a change, or does it in a
> way that doesn't block Zim.

I don't think what you describe is what is happening exactly. When
updating links zim will open each page to be updated just once and
write it immediately. Writes are done atomic, and if they fail there
will be an explicit error.

The only thing I would have to test is whether or not the error is
caught properly and presented in an error dialog. But for sure you
would see it in the debug output (zim -D).

The interesting question of course is why would using spideroak result
in failures while writing pages and how to make things more robust.
What zim does when writing is generating a temporary file and then in
an atomic action replace the target file with this temporary file.
Maybe spideroak already tries to sync the temp file and by that blocks
the replacement. In that case it would be helpful to know if spideroak
has any configuration to exlcude certain file patterns.


> ISSUE 2 - Index Confusion?
> To test the above I made a complete copy of the notebook for SpiderOak to
> synch across the two machines and left the original untouched. Once I
> realised SpiderOak wasn't doing the job, I reverted Zim on both Linux and
> Windows to open the original (untouched) notebook by default. When loading
> on Windows the index pane was showing some of the errors that had occured on
> the copy (i.e. orphan subpages). Re-generating the index cleared these, so
> the issue appears to be that somehow Zim used the index from the SpiderOak
> copy when opening the clean, untouched notebook (in an entirely different
> location).
>
> This seems very odd! How would Zim use the index from one notebook (in a
> different folder) for another notebook?
>
> Both notebooks have "Share" checked.
>
> I had not opened the original notebook at all during this process, so it
> seems that without question that Zim used index information that did not
> apply to it when I re-opened it. How can that be? The root notebook
> file/folder was the same, but it was located in a different folder. Perhaps
> Zim assumes the same root file/folder name means it is the same notebook? If
> so I wonder if this is wise.


I'm confused what you mean by "the root folder was the same, but it
was located in a different folder" - was the notebook location the
same or not ?

When you have the "shared notebook" option, the cache is stored in a
temp file that is related to the location of the notebook. So yes, if
you completely replace a notebook it would still have the old index.
After all, zim has no way of knowing that you did that. (And I would
argue that it is not a common action in regular use, so I don't see
particular benefit in making it detect such cases.)  The way to fix it
is simply to run the "update index" action after you replace the
notebook.

Regards,

Jaap