Zettelkasten Forum


The Archive v1.0.5: Reacting to external file changes (bug hunt!)

While external changes were always picked up by the app, external changes were not displayed in all cases, e.g. after you began editing a note.

As @Basil often pointed out, this is kinda weird when the note as shown by The Archive is out-of-sync.

In 1.0.4 and 1.0.5 (from the Cutting Edge update channel), I changed how the app reacts to external changes. This needs more stress testing before I push it to the main update channel.

What's the problem with external file changes? -- They are indistinguishable from file changes that are effects of auto-saving in The Archive. So you might type away until auto-save is triggered, the file on disk is changed (while you continue to type), the file update is read in by the app and presented as new, and your changes since the auto-save are lost. A trivial approach to make this work is to distinguish between typing and idling, and not updating the displayed text while the user is typing. But the problem of timing remains in principle and will reveal itself again when you begin to type during about the same half second when the app shows the new file contents.

So please try to type, wait 1 second (which triggers idling), and type again. Type erratically. Move the cursor around a bit -- do stuff in the text editor and try to find a glitch :)

Author at Zettelkasten.de • http://christiantietze.de/

Comments

  • imho: the way i would do this, is: remember time of last (auto-)save for each open file. if file mtime is suddenly greater than last save time, an external change must have happened. this might be totally inapplicable to the framework or code you use that might trigger file change / auto-save. just 2c

  • I already do that :) But every write onto the disk necessarily happens after the internal updates, with a likely non-negligible milliseconds delay on spinning disk drives. And when you sync to Dropbox, you'll receive even more file change events due to metadata changes right after the real write operation that cannot be distinguished properly from content changes. (In theory, the FSEvent could report which kind of change happens, but the file system info doesn't help that much in practice.) So the modification date on its own is not a 100% reliable indicator, though it'll get you pretty far in most cases.

    Author at Zettelkasten.de • http://christiantietze.de/

  • I just realized that v1.0.6 seems to have (partially?) regressed back to the pre-v1.0.4 behavior of not always refreshing the currently displayed note when it is changed externally.

    Steps:
    1. Edit a note in The Archive
    2. Wait for 10 seconds
    3. Edit the same note externally

    Result:
    The Archive does not display the recently made changes

    Is v1.0.6 from a different branch than v1.0.4 and v1.0.5, or did you accidentally "unfix" the bug?

  • I have the same document I'm working on in The Archive also open in Typora another screen as my markdown preview, so the sync issue is coming up a lot. It seems to be working so far to save in Typora, flick back to The Archive, select another note, then go back to the target note. Changes are usually registered by then. Whether or not going to another note refreshes The Archive or whether it just gives me something to do while waiting, I'm not sure...but it's looking like the former.

    Those who discover the meaning of life find that it is written in plain text.

    They might not need me; but they might. I'll let my head be just in sight; a smile as small as mine might be precisely their necessity. ~ Emily Dickinson

Sign In or Register to comment.