Thanks Jaap, this was helpful and "zim --index" has helped clean things up.

I am using SpiderOak to sync files and am homing in on the issues, and one I suspect is my having renamed a page with a bunch of subpages. I think SpiderOak is a bit slow picking this up, and if it is done too frequently SpiderOak can leave old files around.

For example, I created a test ".txt" file in Windows with the "New Text Document" menu item, which as you know first creates "New Text Document.txt" and then prompts you to rename it. Well I ended up with both files in the destination, and subsequently propagated back to the source folder!

Doing some manual tests, SpiderOak does pick up deletions, and propagate them, but I think if I rename too quickly it misses them and ends up propagating the pre-renamed file. This makes sense as I know I did rename a Zim page twice or even three times in quick succession.

I have a similar effect with a new file I created and then renamed shortly after. Now I have two pages one with the original name and one with the new name.

I like SpiderOak because it does encryption properly, but maybe I'll try using Syncplicity for this as I think it is quicker.

What does "zim --index" do?
Whad does .zim/index.db do? (I renamed this at some point in my tests but have not noticed any effect, and Zim has neither recreated it nor seems to have had any ill effects! Should I put it back!?)



On 21/01/2013 08:39, Jaap Karssenberg wrote:
On Sat, Jan 19, 2013 at 4:41 PM, Mark Hughes (Zim mailing list)
<> wrote:
I have been using Zim on two Windows machines and keeping the files in sync
without problems. Now I have switched one machine to Ubuntu/debian (Bodhi
32bit non-pae distro).

Copying a Zim Wiki from Windows 7 to Linux worked fine, but I'm having
problems when files are moved from Linux back to Windows 7.

I suspect that Zim tries to find a saved file for a reference, fails,
creates an empty virtual file. Perhaps Zim on Windows 7 reads the Linux
saved file and includes some control character in the name (e.g. looks for a
filename "SomeRef\n.txt" instead of "SomeRef.txt")?

The reason I think this is that if I copy all the files from Linux to
Windows 7 (e.g. using SpiderOak file sync) and then open Zim on Windows 7,
the tree view behaves strangely, and suggests to me that when Zim loads some
.txt files it fails to find the .txt file corresponding some or all of the

Firstly is shows a limited tree - not all the subpages seem to be present.
The tree does however contain all the nodes, and more (!), but most are
invisible. The invisible nodes are revealed as I pass the mouse over them,
sometimes going invisible again depending on what I do.

I can see that there are duplicate top level nodes/pages in the tree, some
with the correct subpages listed, others missing some or all subpages. One
node (referenced in Home) has a lot of sub pages, and appears three times in
the treeview. The first instance appears shows a lot of subpages, but each
is empty when selected (ie. purely virtual pages). This I suppose is because
Zim looked for the ".txt" file, did not find it, and assumed the file did
not exist. The file does exist, so I am guessing that the filename is not
matched for some reason because of the transfer from Linux to Windows.

The filesystems show the same names, so I wonder if when Zim on Windows 7
reads a reference in a file that was saved on Linux, it mistakenly adds "\n"
or "\n\0" or something into the filename because of the different EOL in
Linux. Just a guess!
File names are handled exactly the same. Only difference can be
non-ascii characters if you have different file system encodings
between the two systems.

If I edit one of the virtual pages in Zim, Zim will save over the file that
corresponds to that subpage. I can't however get the tree back to normal.
Did you try running "zim --index" ?

It would be great to be able to move Wiki's between Linux and Windows. Hope
this helps achieve that at some point!
Zim (should) fully that already. I use a lot of file syncing myself
and I know others do as well. So assuming the issue is more specific
to your setup. It might help if you detail how you sync the files:
copy from a share drive, dropbox, rsync, ...



Mailing list:
Post to     :
Unsubscribe :
More help   :

Reply via email to