bug-wget
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-wget] [Win32 Patch] console-close events


From: Ángel González
Subject: Re: [Bug-wget] [Win32 Patch] console-close events
Date: Mon, 16 Jun 2014 23:33:36 +0200
User-agent: Thunderbird

On 09/06/14 16:59, Gisle Vanem wrote:
On Windows, when closing the console, logging off or shutting down the system, the OS sends the proper events to registered console-handlers.
Wget has a ws_handler() in mswindows.c that can handle these events
to cleanup it's tracks. This patch doesn't do anything other than cleanup() may do. It could be used to delete any possibly truncated files. What does Wget do (if anything) on other platforms? E.g. a ' ^Z' with no 'bg/fg' on Unix?
^Z on Unix sends a SIGSTOP, which is not catchable. On both SIGINT and SIGTERM,
wget leaves the half-downloaded file (which allows for later resuming)


Here is a simple patch that I use. Feel free to add it:



+/* Return the name for the console-events we might receive. */
+static const char *ws_event_name (DWORD event)
+{
+  return (event == CTRL_C_EVENT ? "CTRL_C_EVENT" :
+          event == CTRL_BREAK_EVENT ? "CTRL_BREAK_EVENT" :
+          event == CTRL_CLOSE_EVENT ? "CTRL_CLOSE_EVENT" :
+          event == CTRL_LOGOFF_EVENT ? "CTRL_LOGOFF_EVENT" :
+          event == CTRL_SHUTDOWN_EVENT ? "CTRL_SHUTDOWN_EVENT" :
+          "?");
Better something like "UNKNOWN EVENT" ?


static BOOL WINAPI
ws_handler (DWORD dwEvent)
{
@@ -352,6 +364,16 @@
      ws_hangup ("CTRL+Break");
      return TRUE;
#endif
+    case CTRL_CLOSE_EVENT:
+    case CTRL_LOGOFF_EVENT:
+    case CTRL_SHUTDOWN_EVENT:
+      MessageBeep (MB_OK);
+      logprintf (LOG_NOTQUIET, _("\n%s: Got %s. Performing cleanup.\n"),
+                 exec_name, ws_event_name(dwEvent));
+      cleanup();
+      Sleep(500);
+      return TRUE;
+


PS. The above Sleep() seems to be ignored by WinCon. At least I failed to
 make it sleep more than ~500 msec.
There may be a timeout on how long you can stay processing the event.

Why do you need that Sleep() call at all? I would remove  it.


Thanks for sharing your patch!




reply via email to

[Prev in Thread] Current Thread [Next in Thread]