Re: [Zim-wiki] Some issues around sync'd Notebooks

[Stephen LARROQUE]

Hello there,

I think I am experiencing the same issue as Mark Hughes. I am also using
SpiderOak. Can someone tell me what is the file extension that I need to
exclude, to try to use this approach to fix the synchronization issues?

Thanks in advance!
Best regards,
Stephen L.
___
Mailing list: https://launchpad.net/~zim-wiki
Post to : zim-wiki@lists.launchpad.net
Unsubscribe : https://launchpad.net/~zim-wiki
More help   : https://help.launchpad.net/ListHelp

Re: [Zim-wiki] Some issues around sync'd Notebooks

[Mark Hughes (Zim mailing list)]

Jaap,

Thanks for the response. I suspect you are correct but have not verified 
this yet. SpiderOak can be configured to exclude files using wildcards 
(e.g. *.tmp), except for the new SpiderOak Hive feature recently 
added. This works like Dropbox, but if I set up a 'Sync' for any other 
folder I can set a wildcard, so please tell me what extension to use and 
I'll see if that helps (and turn on -D to gather info).


See also my answers below...

Mark

On 09/05/2013 08:30, Jaap Karssenberg wrote:
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).

[snip]
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 ?

Sorry for the ambiguity over root folder.

I made a complete copy of my Zim notebook folder tree in a new location. 
So I had two identical copies of my notebook, one inside my Dropbox 
folder, and one inside my SpiderOak Hive folder. I pointed Zim at the 
latter to do my tests and found the problems. Then reverted to the original.




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.
So there would be two identical copies of the index, which makes your 
first diagnosis seem the most likely (i.e. SpiderOak interfering with 
the temp file and Zim not reporting that in the UI).



___
Mailing list: https://launchpad.net/~zim-wiki
Post to : zim-wiki@lists.launchpad.net
Unsubscribe : https://launchpad.net/~zim-wiki
More help   : https://help.launchpad.net/ListHelp

Re: [Zim-wiki] Some issues around sync'd Notebooks

[Jaap Karssenberg]

On Wed, May 8, 2013 at 6:02 PM, Mark Hughes (Zim mailing list)
m...@happybeing.com 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

___
Mailing list: https://launchpad.net/~zim-wiki
Post to : zim-wiki@lists.launchpad.net
Unsubscribe : https://launchpad.net/~zim-wiki
More help   : https://help.launchpad.net/ListHelp