diff --git a/src/nwconn.c b/src/nwconn.c
index f6d7547..bf558c6 100644
--- a/src/nwconn.c
+++ b/src/nwconn.c
@@ -2741,8 +2741,36 @@ static int handle_ncp_serv(void)
       /* 0.99.pl18,  25-Sep-99
        * these log/lock functions are not well tested and perhaps not
        * ok .
+       *
+       * The WebSDK Synchronization Services list used here starts the old
+       * file-log/file-lock group at NCP 0x2222/03.  I have not found old
+       * 0x2222/00, 0x2222/01, or 0x2222/02 synchronization endpoints in
+       * that list; keep the main 0x2222 switch starting this group with
+       * Log File unless another primary source identifies earlier calls.
        */
       case 0x3 : { /* Log File */
+        /*
+         * NCP 0x2222/03 Log File (old) logs one file name in the calling
+         * client's file-log table.  The request uses the old directory
+         * handle plus path layout:
+         *
+         *   byte  DirectoryHandle
+         *   byte  LockFlag: bit 0 asks the server to lock immediately
+         *   word  LockTimeout, in units of 1/18 second
+         *   byte  FileNameLen
+         *   bytes FileName
+         *
+         * SDK reply: no reply data.
+         * SDK completion: 0x00 success, 0x82 no open privileges, 0x96
+         * server out of memory, 0xfe timeout, 0xff lock error.
+         *
+         * A logged file may name a file that does not exist yet; locking it
+         * reserves that name for the client.  The newer Log File variants
+         * are 0x2222/105 and 0x2222/87/36, while 0x2222/04 and 0x2222/106
+         * lock the accumulated file set.  MARS-NWE records this old layout
+         * through nw_log_file(), which is the same table consumed by the
+         * file-set Lock/Release/Clear handlers below.
+         */
         struct INPUT {
           uint8   header[7];       /* Requestheader */
           uint8   dir_handle;