removed config files do not disappear from the GUI list

[cron2]

So, @lstipakov made me fight windows OpenVPN to test the DCO/server functionality, and I was copying .ovpn files all around the place and then cleaning up stuff again... and I found something which I think is a bug.

This happens with the GUI bundled in our official 2.6.13-I001 installer (I002 is not on swupdate yet), so no private builds involved yet. No upgrade installation either, removed the old install and installed fresh, with default options.

There are a number of .ovpn files already in c:\program files\openvpn\config, and openvpn-gui.exe is running.

Add a new .ovpn file, right-click GUI, new file is visible.

Remove an .ovpn file (either the new one or one of the others), right-click GUI, freshly-removed config is still visible - trying to start it will of course cause an error (IService > OpenVPN exited with error: exit code = 1).

I do not understand enough windows coding to figure out how the GUI notices that "new files have appeared" and why it does not notice "files have been removed".

[lstipakov]

I am on it.

Bisecting: 45 revisions left to test after this (roughly 6 steps)
[67a8db7664648e60108edead231c7b813b46034c] PLAP: Do not show profiles with no management address

[lstipakov]

commit 6932c5e7109330d8cc75afca8980c80e457ef275
Author: Selva Nair <[email protected]>
Date:   Wed Jul 20 20:58:04 2022 -0400

    Change the logic of releasing persistent connections in OnHold

    (i)
    State is changed to detached before auto-starting
    so that OnHold() will see state = resuming and keep the hold.

    State is set to disconnected instead of detached on detach
    so that manual starts will release the hold automatically.

    End result: While connecting automatically, do not release if
    management-hold is on. But while started manually, release
    from hold so that connection can complete without further
    user action.

    In normal use of automatic service, one would not add management
    hold into the config. However, if the user disconnects the connection
    the GUI puts it on hold, and we do not want to auto-start it after a
    lock-unlock or some other automatic action.

    (ii)
    Also, currently, for persistent connections, the status
    window is not shown automatically which feels unnatural in
    real use. Instead, popup the status window when connection
    is manually initiated. Its not popped up when automatically
    attached to or if silent_connection is on.

    Only persistent connections are affected by the change.

    fixup: config file list is not recreated from scratch when
    enable_persistent == 2 (auto attach mode) to avoid losing info
    such as auto_connect = false on detached connections.

    Signed-off-by: Selva Nair <[email protected]>

[cron2]

@selvanair this sounds as if this is a "known effect" (config file list not recreated from scratch) - but it still feels weird, and I'm sure I'm not understanding all the deails...?

[lstipakov]

Previously if one sets "Persistent Connections" to anything different from "Auto", we will recreate configs list. However, after this commit it is no longer possible.

@selvanair is it so, that we don't recreate configs list only not to lose "auto_connect" state? Maybe this could be separately preserved across recreation?

[selvanair]

It has been a while and I do not recall the details. I can't even completely comprehend my own commit message right now! Will take a look.

That said, it must be possible to retain the "auto_connect" info and recreate the list but probably I thought it was complicated at the time... After all the user can fix it by restarting the GUI and how often do they delete configs.
Alternates are (i) add a way to delete config files from the menu and discourage deleting manually from the file system or (ii) do a reverse scan of the list to grey-out configs not in file system.