Feature: Notification when the database file has been updated while the program is open

[angrygreenfrogs]

Myself like some other users use a shared password file located either on a network share or on a file sharing folder like dropbox.

It's a common behavior I believe that many users leave their password file open constantly (but locked), and when you have multiple users this can occasionally lead to user A making changes while user B has left the file open, and user B then makes a change and saves overriding user A's changes.

I think a simple but fairly effective solution to this issue would be to notify the user if the underlying file has been changed.

Then the user can decide to re-load the file (accepting any lost unsaved changes) or continue and know that they'll have to save their changes elsewhere then merge (but at least they know instead of accidentally overriding the updated file). This feature + enabling auto-save would basically get rid of the shared file issue unless 2 users save the file at almost the same moment, which is too rare to worry about.

Here's an example of the same dialog I get from TextPad when it detects the underlying file has changed:

[rich123]

I am noticing a theme here. :)

As a result, commit 993ffe5 on new branch shared-safes, contains a beginning skeleton of a change monitoring system for PWGorilla's safe files.

If you can run the source bundle (depends on your having Tcl/Tk and dependencies installed natively) then as the feature progresses it would be good to have some testing with your actual situation to verify that the feature is working as planned.

[angrygreenfrogs]

Oh wow, thanks so much. I'd be very glad to at least test to help out. I'll get my local system setup here with all the source bits.

Cheers!

[rich123]

You can download a version of Gorilla with the initial changes to watch for file updates by other copies of Gorilla from this branch:

https://github.com/zdia/gorilla/tree/shared-safes

Near the bottom right of that page will be a button "Download zip". Pushing it will give you a zip file containing the code for this branch.

Unpack the zipfile somewhere on your local system (preserving the directory structure inside). To launch it, open a terminal window, change directory into the sources/ directory, and run the gorilla.tcl file. If your system is setup properly, you should be able to do ./gorilla.tcl and get it to launch. If not, then try one of either "wish gorilla.tcl" or "tclsh gorilla.tcl".

Then please put this version through its paces with testing in your environment. Make changes locally from two running copies, make changes remotely from different copies running on different machines. Make changes across a dropbox sync point (if you use dropbox), etc. Note, you can use any other copy of Gorilla to make remote changes, you just want to test if this test copy detects that the other copy made a change.

Note, with dropbox, there may be a time delay before changes sync between machines. There is no way that any program will be able to detect that changes have been made remotely if it can not also see those changes locally, so with systems like dropbox there will always be some small time window during which changes can not be detected, and so there will still be a small window of risk for data loss. As long as that window is small then the risk of overwriting changes will also be small.

[angrygreenfrogs]

Hi Rich,

Wow hey that's awesome - I've just git clone'd a copy and switched over to that branch so I can track any further updates.

No worries, I'll give everything a good testing.

At a first glance it does seem to work quite nicely! It works well with local changes and also with the auto-save feature turned on.

It's great already / big improvement how it is - however I have a suggestion if you're interested:

The way it's structured now, the check is only performed when you save, which isn't quite as good as being warned when the change is detected, which would give you the chance to reload before you even started making changes. This is similar to the use case from (for example) TextPad or Kdiff where it must be checking periodically (or using a native file monitoring API which would be way too much of a pain for you). I did some testing and how it seems to work with those programs is the user is only prompted when the program gets focus again, or while the user is actively using the program (so the checking must be disabled when the app doesn't have focus).

Gorilla could perhaps do something similar and check say upon save, upon gaining focus, and regularly every 5-10 seconds or so, but only while the program has focus?

That said, if that's too much, then really this is fantastic.

I'll do some more detailed testing, mess around with dropbox, etc.

All the best,
Andrew

[rich123]

You are correct, at the moment the only check that occurs is as you attempt to save the current database out to disk.

Your suggestion of other checks is intriguing. The proper way to support something like this is to utilize the OS change notification interfaces, but alas native Tcl provides no interface to those systems. I am aware of a compiled Tcl extension for Linux to hook into the notification interfaces, but that one is of no help on Windows or MacOS. Polling the file every few seconds would work, but for anyone on a laptop running on battery power it would be needless power drain.

What has occurred to me is that there might be a happy medium between the new "check only at save" and the "poll every 5 seconds" methods. That one is check upon initiating an edit, and also check upon unlock. Both of those events are points where a user would likely want to know that the file has changed, and at least with unlock, should provide most of the usefulness of watching out for changes without being too noisy or power wasteful at the same time.

[angrygreenfrogs]

Hi Rich,

I've been testing and regularly using the current git version this past week - every case I've tried works perfectly. Local changes and changes via a remote Dropbox (my primary use case) always result in the pop-up dialog showing up as expected.

It's particularly useful when auto-save is enabled.

I've tried saving password changes as well as preference changes and both resulted in the dialog showing up as expected when there would be a conflict.

Subsequent saves after choosing to override also work fine.

Basically seems like a solid one already.

About the further extension on the feature:

Yeah totally understood... I looked into it a bit myself and unfortunately every OS requires a separate library for file monitoring.. it'd be a big pain to implement and maintain.

Ahh, good point about polling on edit or unlock. Yes, that'd be a great compromise. Then you'd catch any new changes upon unlocking and most importantly it'd stop you from wasting your time on editing a change that you'd then to have to manually merge in.

Cheers,
Andrew