wildcard include failing with FormatMessage() error:(15100)

[fliespl@…]

Hello, I have tried adding wildcards on windows with include like I do on linux and not sure why it fails

include e:/workspace/tools/pma-slack/.nginx.conf;

works correctly, while

include e:/workspace/tools/*/.nginx.conf;

fails with:

f:\nginx>nginx -t
nginx: [emerg] FindFirstFile() "e:/workspace/tools/*/.nginx.conf" failed (123: FormatMessage() error:(15100)) in f:\nginx/conf/nginx.conf:75
nginx: configuration file f:\nginx/conf/nginx.conf test failed

Maybe it's not supported, but haven't found this info listed in "Known limitations".

Help would be appreciated :)

[Maxim Dounin]

On Windows, FindFirstFile() interface only support wildcards in a file name, but not directories. It is general limitation of file mask, and applies to all system tools. For example, here is dir command output:

c:\>dir temp*\test
The filename, directory name, or volume label syntax is incorrect.

c:\>dir temp\test*
 Volume in drive C has no label.
 Volume Serial Number is 5C00-FB45

 Directory of c:\temp

10/09/2019  10:37 PM                 7 test
               1 File(s)              7 bytes
               0 Dir(s)   9,941,815,296 bytes free

The "123" error is "The filename, directory name, or volume label syntax is incorrect", see ​here. Looks like you have no english language files on your system, and that's why FormatMessage() cannot print text description. Unfortunately, the error code it returns does not match documented ERROR_RESOURCE_LANG_NOT_FOUND for some reason, hence nginx doesn't try to fallback to system default language. This probably can be improved, especially given that ERROR_MUI_FILE_NOT_FOUND error (15100) seems to be common enough, and my own testing suggests that it can also return ERROR_RESOURCE_TYPE_NOT_FOUND error (1813) if the language requested is not available. That is, falling back to the default language on all FormatError() errors might be an option, patch below. It would be great if you'll test if it helps to get better error messages on your system.

# HG changeset patch
# User Maxim Dounin <mdounin@mdounin.ru>
# Date 1570653718 -10800
#      Wed Oct 09 23:41:58 2019 +0300
# Node ID f96d7b3ab39b9152f2e77374c6db6b3517f57703
# Parent  7ec8ef26e5e455f734d58d52b745ddf7b82ead57
Win32: improved fallback to default language on FormatMessage() errors.

FormatMessage() seems to return many errors which essentially indicate that
the language in question is not available.  At least the following were
observed in wild and during testing: ERROR_MUI_FILE_NOT_FOUND (15100),
ERROR_RESOURCE_TYPE_NOT_FOUND (1813).  While documentation says it
should be ERROR_RESOURCE_LANG_NOT_FOUND (1815), this doesn't seem to be
the case.

As such, checking error code was removed, and as long as FormatMessage()
returns an error, we now always try to fallback to the default language.

diff -r 7ec8ef26e5e4 -r f96d7b3ab39b src/os/win32/ngx_errno.c
--- a/src/os/win32/ngx_errno.c	Tue Sep 24 18:08:48 2019 +0300
+++ b/src/os/win32/ngx_errno.c	Wed Oct 09 23:41:58 2019 +0300
@@ -22,7 +22,7 @@ ngx_strerror(ngx_err_t err, u_char *errs
     len = FormatMessage(FORMAT_MESSAGE_FROM_SYSTEM,
                         NULL, err, lang, (char *) errstr, size, NULL);
 
-    if (len == 0 && lang && GetLastError() == ERROR_RESOURCE_LANG_NOT_FOUND) {
+    if (len == 0 && lang) {
 
         /*
          * Try to use English messages first and fallback to a language,

[Maxim Dounin <mdounin@…>]

In 7585:746567d633ac/nginx:

Win32: improved fallback on FormatMessage() errors.

FormatMessage() seems to return many errors which essentially indicate that
the language in question is not available. At least the following were
observed in the wild and during testing: ERROR_MUI_FILE_NOT_FOUND (15100)
(ticket #1868), ERROR_RESOURCE_TYPE_NOT_FOUND (1813). While documentation
says it should be ERROR_RESOURCE_LANG_NOT_FOUND (1815), this doesn't seem
to be the case.

As such, checking error code was removed, and as long as FormatMessage()
returns an error, we now always try the default language.

[Maxim Dounin]

The patch to improve error messages was committed, and will be available in the next release. The original problem, as already explained above, is a Windows limitation, not an nginx bug.