sync issue across different linux and tomboy versions

[poe101]

Sync worked between one machine and server but when I set up a second machine to sync with the same database it fails to sync all notes. Perhaps there is a quick answer in that linux and tomboy versions need to be at a certain level? If so I will upgrade where needed. If not is there more information I can/should provide?

DellServer / ToshibaLaptop / SilverstoneDesktop Linux 3.2.0-38 / Linux 3.0.0-32-generic / Linux 3.5.0-21-generic n /a Tomboy 1.8.0/ Tomboy 1.12.0 Rainy 0.2.3/ n/a n/a

many thanks for any support

[Dynalon]

Please start Rainy with the "-vvvv" parameter. It will then create a debug.log file with all output. Try to reproduce the case with the 2 syncs and the one that fail, and please post the content of the debug.log in a gist file: https://gist.github.com/ and link it here. You can remove any note content from the log to keep your privacy, but please do not remove Rainys log messages.

It is also helpful if you start Tomboy from a terminal, and post the output of that, too (both syncs).

[poe101]

Re "Please start Rainy with the "-vvvv" parameter....and please post the content of the debug.log in a gist file"

Thanks for the response Dynalon. I spent some time on this yesterday but the output in the debug file is something like 24Mb and 20k lines so far. As a result it is difficult to find and isolate relevant lines.

In order to have test output with minimal but relevant detail, my plan is...

1> backup and clear the .local/share/tomboy/ directories on each client and 2> delete .rainy/rainy-0.2.3/ directory on the server and reinstall
3> Start rainy and run tests as above (with clean database)

on completion of tests

4> restore my client backups 5> clear and reinstall Rainy on the server

Is it ok to take this approach (as my notes are backed up and accessible in text files)?

[Dynalon]

Sounds good, but do also backup (and delete for testing) the ~/.config/tomboy/ directory!

[poe101]

Sorry for the delay.

The test is failing at the first hurdle (initial sync to server is failing) so I think I may have broken something else.

What I did...

To prepare for tests...

Backup and clear ~.local/share/tomboy/ directory on each client

    $ cd ~.local/share
    $ mv tomboy tomboy-poebackup
    $ mkdir tomboy

Backup and clear ~/.config/tomboy/ directory

    $ cd ~/.config/
    $ mv tomboy tomboy-poebackup
    $ mkdir tomboy

Cleared and reinstalled rainy on the server

    $ cd ~/.rainy
    $ mv rainy-0.2.3 rainy-0.2.3-poebackup
    $ unzip rainy-0.2.3.zip

Ran tests...

Started rainy on the server

    $ sudo mono --debug Rainy.exe -c settings.conf -vvvv

On Tosh Client Started tomboy from the teminal $ tomboy –debug Created a note called: “Test1NewNoteOnTosh” Started sync

Note is created and visible after restart but Sync Fails (no details in Sync Message window)

Outputs are here https://gist.github.com/poe101/bf0d6628509d7d07c299

[Dynalon]

That's a hell of a good bug report :)

But I still don't know why it is not working. From the logs I can tell that the initial authorization fails, so the Sync is not the problem but OAuth. You did use the standard johndoe/none combination as I can see, which make this more confusing.

Could you try not to run rainy with root rights, so do not use sudo to run it? That shouldn't be necessary anyways. You might need to adjust the rights of the ./data/ path and all the files there in, as they would have been created by root. You could also start from scratch with a new rainy-0.2.3.zip in a different folder.

What Linux distribution are you using on the rainy server (uname -a)?

[poe101]

It looks like forcing re-authorization on each client cures the major issue but leaves some anomalies.

"Could you try not to run rainy with root right" I had originally run it without sudo and added sudo to see if it would overcome any possible rights issue - now running it again without sudo.

"adjust the rights of the ./data/ path and all the files there in, as they would have been created by root" I confirmed that files owner and groups in /data are under my username (as I originally started it without sudo) - i.e. no change made. incidentally user name on all machines is the same so there should be no uid issues.

"start from scratch with a new rainy-0.2.3.zip in a different folder" Tried this but was still getting the same result

Server version: Linux ubuntuloft 3.2.0-38-generic #61-Ubuntu SMP Tue Feb 19 12:18:21 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux (Ubuntu 12.04.2 LTS)

Tosh Client Version: Linux Tosh 3.0.0-32-generic #50-Ubuntu SMP Thu Feb 28 22:33:24 UTC 2013 i686 i686 i386 GNU/Linux

Silver Client Linux Version: Linux Silver 3.5.0-21-generic #32-Ubuntu SMP Tue Dec 11 18:52:46 UTC 2012 i686 i686 i686 GNU/Linux

Other things I tried... Copied the original ssl files (ssl-cert.pvk & ssl-cert.cer) from backup into the rainy directory- no difference Created a new .Rainy (original was .rainy) directory, then unzipped and ran rainy from there – no difference

\ What got Sync working again on Tosh... ** With server still running from the new .Rainy directory I re-entering the server info on the Tosh client in Tomboy Sync setup and forced new authorisation (i.e. opened the web “Tomboy Web Authorization Successful” page in the browser. I saved the new settings and sync on Tosh started working again. I don't think there was anything different in what I entered compared to what was already.

Initial sync said '2 notes updated' (only one note in the database at this point?) Subsequent sync said 0 notes updated (as expected as no changes or new notes created) Made a change to the first note and started a sync which reported 1 note updated (as expected) Can see the original and updated note text in the rainy.db file on the server (as expected)

\ Similarly Forcing re-authorization on Silver got sync working :-) **

However Notebooks are not syncing as expected - instead of creating a new notebook on the remote client it is creating a note - see attachments, specifically tests.txt which provides more detail.

Finally Tosh Terminal did crash at some point - details are in the logs.

Outputs and test scenarios are here https://gist.github.com/poe101/94438c72e27890ad961b

[Dynalon]

Thanks for your detailed testing, that really helps a lot! I am not sure why authorization did not work in the first place. Whenever you use a new rainy.db database, the clients must re-authenticate, maybe something got messed up.

As for the notebooks not working I have an idea why it is not working, as the notebooks are assembled via the tags fields (not visisble in tomboy) and the tags do not get synced correctly. I will investigate that further.

[poe101]

Very happy to be able to support in the only way I can!

[enekux]

I am having the same problem as commented here! Everything was working just fine until one month aprox. now I can not sync anymore. I will send u the logs as soon as possible.

[enekux]

Hi again,

for me the problem is solved.

I forgot about the known issues shown in here: http://www.notesync.org/GETTING_STARTED.md

"6. Known issues

There are currently some issues in Tomboy and Tomdroid that you should know of before using Rainy.

Tomboy
    There is a bug in Tomboy regarding note templates, especially the "New Note Template" note that will always reappear and cause conflicts. If you happen to get a window in Tomboy telling you that a note with the title "New Note Template" already exists, choose to rename the local note version. Do not chose overwrite the local note!. The renamed note must be kept and not deleted."

I was overwriting the templates in my clients and this is the reason why then the syncs were failing.

I hope this will help. thank you.

[Dynalon]

@poe101 glad that this could sort the issue out. I am closing this issue then.

@enekux If the suggestion reported by @poe101 did not help you, feel free to open a new issue so we can work on that!

[Dynalon]

To clarify the issue as a help for other users; the bug causing the trouble is not in rainy but Tomboy itself, the bug is reported upstream here: https://bugzilla.gnome.org/show_bug.cgi?id=665679