encfs4win does not close gracefully upon receiving WM_CLOSE

[Zero3]

When I try to close encfs4win 1.10.1-RC6 at the password promt in foreground mode, using Qt's QProcess#terminate() method, encfs4win does not quit. Relevant part of the Qt docs:

On Windows, terminate() posts a WM_CLOSE message to all top-level windows of the process and then to the main thread of the process itself. On Unix and OS X the SIGTERM signal is sent.

Console applications on Windows that do not run an event loop, or whose event loop does not handle the WM_CLOSE message, can only be terminated by calling kill().

Unless I made an error in my code (which is very much possible, of course), it would appear like encfs4win does not handle the WM_CLOSE message as described above.

Is it possible that this could be implemented, so that external utilities can close encfs4win gracefully?

[jetwhiz]

From what I understand, if you send a SIGTERM signal to encfs4win (kill), it should gracefully exit. Does the program not exit cleanly when you use kill to send the SIGTERM signal to encfs.exe?

Since encfs4win operates as a console application, we do not have an event loop (so we can't catch the WM_CLOSE message). In this situation, the correct way to terminate the program is to send a SIGTERM signal to it.

[Zero3]

As far as I understand the docs, kill() uses the Windows TerminateProcess API which forcibly kills the process. This start of this old (but still relevant?) article describes the issues with doing this, and why the WM_CLOSE method is a better alternative: http://www.drdobbs.com/a-safer-alternative-to-terminateprocess/184416547

As expected, encfs4win does not close gracefully when kill()ed. I verified this by trying to navigate to the mounted folder of the killed process which leads to a generic "endpoint not connected" error from Windows.

Killing the process forcefully thus does not work in practice, and did not seem like a sensible idea in the first place anyway. If you cannot / will not catch the WM_CLOSE message, I guess the only remaining options are either emulating a CTRL + C console event (messy, and does not appear to be present in standard libraries like Qt) or using a Dokan unmount command?

[jetwhiz]

After further reading, it seems that WM_CLOSE is sent to windowed applications and CTRL_CLOSE_EVENT is sent if the application is a console (like encfs4win).

See:

• https://social.msdn.microsoft.com/Forums/en-US/07a6feef-22a9-44c2-9a87-7f41a6338ef0/how-does-postmessagewmclose-shutdown-a-console-app?forum=vcgeneral
• https://blogs.msdn.microsoft.com/oldnewthing/20040722-00/?p=38373

We do handle CTRL_CLOSE_EVENT, so I would imagine that encfs4win should exit gracefully when you terminate it in that fashion. Have you tried your code with other programs to see if they exit correctly?

[jetwhiz]

Hi @Zero3 -- were you ever able to determine the cause of this issue, or does it still exist just for encfs4win?

[Zero3]

@jetwhiz my pet project has been on pause because of the BSOD crashes. I see that you released a new version that should fix some of these, so I will try to give this a shot once more soon :).

[jetwhiz]

Hi @Zero3

Did you ever get the chance to debug this any further to determine the issue?

[Zero3]

@jetwhiz I moved on from my project because of the many issues I ran into :(. So I did not get the chance to further debug the issue. Sorry.

[jetwhiz]

No problem, @Zero3! The latest version of encfs (1.9.5) includes an unmount command line option now, which will be included in encfs4win in our next release series. This will be the appropriate way to unmount and close an encfs4win mount rather than sending WM_CLOSE. It is also still possible to send a CTRL+C (CTRL_CLOSE_EVENT) message to exit as well.

If any other related issues pop up with future experimentation with encfs4win, please re-open this issue or begin a new issue.