#1826 Synchronization cannot be interrupted, it can hang the app

KeePass_2.x
open
nobody
None
5
2014-02-12
2014-01-27
miroxlav
No

ProgressBar window "KeePass - Synchronizing..." has Cancel button disabled and "X" close button does no action, too. This sometimes leads to dead end.

On my machine, file sync sometimes cannot proceed, although before sync step, there is a check for server availability. When problem happens, progress bar is stuck exactly at 5%. I assume that first 5% is some sync preparation. So when such a freeze happens, "Cancel" is disabled and pressing "X" button makes window fade and Windows indicates that the application is unresponsive. There is no other solution than killing the KeePass.

Would you add possibility to cancel the sync and/or sync timeout?

Discussion

1 2 > >> (Page 1 of 2)
  • Paul
    Paul
    2014-01-27

    There are some sync improvements in 2.24. What version are you using?

    cheers, Paul

     
  • miroxlav
    miroxlav
    2014-01-27

    I was at 2.22. After your question I switched to 2.24. Changelists at 2.23 and 2.24 seem to address different aspects of sync. At first sight of 2.24, it seems that "X" button still does not stop the sync and also Cancel button remains disabled. It seems that user can be still forced to kill KeePass on failure at this point. To confirm, I need to wait until the sync problem reoccurs, what can be longer time. If you wish, we can close the ticket until I can confirm the problem in 2.24.

    cheers, Miroslav

     
  • miroxlav
    miroxlav
    2014-02-04

    The same problem just re-occured in version 2.24. It seems there are no changes in behavior since earlier versions.

     
  • Paul
    Paul
    2014-02-04

    What is the sync path and why is the server not available?

    cheers, Paul

     
  • miroxlav
    miroxlav
    2014-02-04

    Path: \\SOMENAME-PC\Users\SomeUser\Documents{DB_BASENAME}.backup

    The server actually is available, because the condition of the sync trigger is "Remote host is reachable (ping)" with parameter "SOMENAME-PC". So the condition passes, but then it looks like if opening the remote file silently fails (witout error message) due to an unknown reason. And then the dead-end scenario occurs.

    I have heard from programmer more experienced in .NET than me that he has seen similar condition in his app, too: network connection to a resource fails without an obvious reason, even if connection looks like 100% error-free. So I wonder if sort of this problem is not happening here: Ping passes, but then opening fails. That is OK, the actual problem is that the dialog box cannot be canceled or closed by user or it is never timed-out, user has to kill the KeePass.

     
  • miroxlav
    miroxlav
    2014-02-04

    (I'm not sure if the connection action literally fails, maybe it just HANGS without signs of failure or timeout.)

     
  • Paul
    Paul
    2014-02-04

    Instead of ping try the condition "if file exists".

    cheers, Paul

     
  • miroxlav
    miroxlav
    2014-02-04

    I have changed the condition. Let's see if this workaround helps...

     
  • greywolve
    greywolve
    2014-02-05

    I have the same issue accessing a remote database file via webdav ... the program stops immediately responding and nothing happens ... I have to force close it and to restart ... but I can confirm that the webdav ressource is available and responding. I don't know what happened it started this behaviour after a restart - curious - it worked before.

     
  • miroxlav
    miroxlav
    2014-02-12

    On my PC I observe that suggested condition "if file exists" helps to prevent running into the UI deadlock (which does not allow canceling and has no timeout). But the UI deadlock can still occur in different scenarios (see greywolve's post above) so implementing an exit path would help.

     
1 2 > >> (Page 1 of 2)