U1 prevents deleted notes from beeing created again

[Cornelius Hald]

If you delete a note on U1 either through the web interface or though sync, it is not possible to later add a note with the same GUID again. This is a problem if a user wants to restore a backup of his notes.

Steps to reproduce:
1.) Create some notes in Tomboy and sync with U1
2.) Go to .local/share/tomboy/ and create a backup copy of NoteA
3.) In Tomboy delete NoteA and sync
4.) Shutdown Tomboy and copy the backup of NoteA back into the directory
5.) Start Tomboy again and sync

The result is a "500 internal server error".

I suspect that U1 keeps a list of deleted GUID and prevents add/update operations for already deleted GUID. There might be several (good) reasons to do so. Still, if this is "by design", then we need a proper error response + a proper error message in Tomboy. Otherwise people like me are sitting there hours and hours wondering why a certain note won't get uploaded.

@Sandy: I also subscribed you, because it could be interesting how Snowy handles this and also because of the question whether or not this behavior is intended.

@U1-Team: Is there a way to reset the list of used GUIDs? Because of all the testing I already have 3 defect U1 accounts.

[Cornelius Hald (hald)]

I have just checked against the latest version of Snowy and there the problem does not exist. This behavior is not defined in the spec, not handled by Tomboy and not implemented in Snowy, therefore I think it's a clear U1 bug and should be fixed here.

[Rodrigo Moya (rodrigo-moya)]

This bug should be fixed with the branch associated with bug #462245

[Cornelius Hald (hald)]

Rodrigo, are you sure about this? Bug #462245 is about Desktopcouch. Also there seem to be no solution, or am I reading it wrong?

Also I noticed that if I create the described situation, U1 now returns the following error:

Could not save note record: ResourceConflict(('conflict', 'Document update conflict.'),)

That's new, so something has changed. Maybe we could at least get the UUID of the conflicting note in this error message. Then I would have a chance to debug this problem when it occurs with my users (just happened again). Of course a fix would be even better :)

[Rodrigo Moya (rodrigo-moya)]

Yes, our server uses desktopcouch API internally, so yes, it is the same bug. It's being deployed to the server soon

[BlaWiz (blawiz)]

I'm still having this problem, but made a workaround-script. Start up tomboy first, then:

#set variables
backuppath="/home/user/backuptomboy"
tomboypath="/home/user/.local/share/tomboy"
backupcount=`ls $backuppath|nl|tail -n1|awk -F " " '{print $1}'`

#generate command to delete all files and dirs from the tomboy-dir
echo "rm -r $tomboypath/*"

#generate commands to make dummy files, probably smart to only generate 100 at a time, since this will make 100 pop-up windows, that you have to close again.
counter=-10; while [ $counter -lt $backupcount ]; do echo "tomboy --new-note gennote_$counter";let counter=counter+1;done

# generate commands to copy old files to dummy-files
counter=1;for i in $backuppath/*; do randomfile=`ls $tomboypath|head -n$counter|tail -1`;echo "cp $i $tomboypath/$randomfile";let counter=$counter+1;done

# now the backed up files have new names and sync should work!