GNOME Bugzilla – Bug 603815
Note Directory Watcher changes <last-change-date> of new notes
Last modified: 2017-07-31 12:38:39 UTC
When newly synced/copied .note files are added to the notes directory, the Note Directory Watcher seems to edit the <last-change-date> value to the current time, even though the content hasn't changed. This is particularly noticeable when switching to a syncing system which uses this plug-in (in my case, unison), as all files now have the same last modified date. This obviously makes the recent-notes list less useful. It also makes it difficult to keep different sets of notes in sync, as each copy results in an updated <last-change-date>, which I guess would just keep propagating back and forth.
The fix is probably as simple as changing this line to use ChangeType.OtherDataChanged: note.LoadForeignNoteXml (noteXml, ChangeType.ContentChanged); But I'd like to test out a few common scenarios first.
I hope you don't mind a non programmer commenting in here, but I've noticed that tomboy re-saves notes whenever they are open. I think this will have consequences for your proposed fix. Suppose I'm using Unison to sync notes on two machines A, and B. Note on A is amended and saved. No sync is performed and the next day I use machine B. I view the same note there - it doesn't have my latest edits because I never ran a sync, so I go and sync up with Unison. Unison sees that the note on B has a more recent save date than note A, even though note A has the more recent content. I expect this risks losing the edit on A. Only solution might be to give users an option to turn off auto-saving or to only save when changes have been made.
On Thu, Jan 14, 2010 at 4:21 PM, Jacek <zdz@happysheep.me.uk> wrote: > I hope you don't mind a non programmer commenting in here, but I've noticed > that tomboy re-saves notes whenever they are open. I didn't know this, it seems to me that the modified date on the files should only change when content is changed. > I expect this risks losing the edit on A. Actually, my experience with Unison is that since both files have a newer modified date than specified in the archive files, it will show a conflict and request user resolution. At least, that's the case with my Unison topology, which is actually A <-> C <-> B (I have a server in the middle of all syncs).
(In reply to comment #2) > I hope you don't mind a non programmer commenting in here, but I've noticed > that tomboy re-saves notes whenever they are open. Yes, it does. > I think this will have > consequences for your proposed fix. I don't think so. What this bug is about has no effect on how often the actual files are modified. It is about changing some elements in the note XML that store information about last time the content changed.
(In reply to comment #) > Actually, my experience with Unison is that since both files have a > newer modified date than specified in the archive files, it will show > a conflict and request user resolution. Yes, but tomboy notes are saved with incomprehensible file names so where my wife and I use the same account on two machines, there's no way to tell from the unison gui which way to sync any particular tomboy note-file. (In reply to comment #4) > I don't think so. What this bug is about has no effect on how often the actual > files are modified. It is about changing some elements in the note XML that > store information about last time the content changed. Thanks for the explanation. I guess that means that unison won't play nicely then, as I understand it checks the physical properties of the files it syncs. Not sure if other sync services like ubuntu one use the metadata? conduit?
(In reply to comment #5) > Thanks for the explanation. I guess that means that unison won't play nicely > then, as I understand it checks the physical properties of the files it syncs. > Not sure if other sync services like ubuntu one use the metadata? conduit? Correct, both U1 and Conduit use the metadata stored in the Tomboy XML, and as far as I know don't look at file modification timestamps at all.
I am experiencing the same issue with syncing my Tomboy notes using SpiderOak's on-line backup sync feature with Note Directory Watcher. If I enable NDW in Tomboy on each of my machines (A and B) and make a new note on machine A, the note will propagate back and forth through SpiderOak: A > SpiderOak > B > SpiderOak > A > SpiderOak > B... Also, since SpiderOak maintains a version history the same note continues to save in my SpiderOak account as a different version. Of course as the note continues to save the same version of itself over and over it starts to consume my on-line storage space. I see you have this issue targeted for v1.4.0. I tried to compile and install v1.4.2 from the tarball but got into the whole dependency mess and after installing 70+ packages threw in the towel... apparently I can't get there from here! I'm running: Ubuntu: 10.04.1 Gnome: 2.30.2 Kernel 2.6.32-27 (i686 and x86_64) Tomboy: 1.2.1 mono: 2.4.4 Is there a Tomboy v1.4.2 compiled for Ubuntu 10.04 (386 & 486) that I can install? That is if the fix is there? Thanks
I am experiencing this issue (or one seemingly related to it) as well. I am running two instances of Tomboy (each as a different user) but with a shared note directory. Often they will seem to get in a race and touch the last-modified time on each note. At other times, new text I have typed in will suddenly disappear 5 seconds later (this seems related to the 5 second delay in the code of this plugin). Is there any chance of a fix? Anything I can do to help further investigate?
Why are you using the shared directory? Is this a way of having _shared_ notes?
(In reply to comment #9) > Why are you using the shared directory? Is this a way of having _shared_ notes? Yes
Does the Tomboy log show what is happening? I haven't tested this configuration before.
(In reply to comment #11) > Does the Tomboy log show what is happening? > I haven't tested this configuration before. It does not, unless there is something I can do to make it be more verbose. (In theory, it appears that there should be some messages at the level of DEBUG.)
Ug: this is part of the code I never have looked at. I took a quick peak, but nothing sounds out. There is verbose logging, but sadly it isn't accessible from outside the class. We could maybe build a test version with a lot of debug logging. (would you be interested in that?)
(In reply to comment #13) > Ug: this is part of the code I never have looked at. I took a quick peak, but > nothing sounds out. There is verbose logging, but sadly it isn't accessible > from outside the class. We could maybe build a test version with a lot of debug > logging. (would you be interested in that?) Yes, I would definitely be interested. To get started I will learn to build the code from git.
Jim, Did you get anywhere with this?
The Tomboy team has moved from GNOME Bugzilla to GitHub for bug reports and feature requests: https://github.com/tomboy-notes/tomboy/issues/ Closing this report as NOTGNOME as part of Bugzilla Housekeeping (bug 781054) to keep tasks in one place. Please feel free to transfer this task to GitHub if this task is still valid in a recent Tomboy version. We are sorry for the inconvenience.