> Hello! > > On Tue, Nov 01, 2022 at 08:15:48PM +0900, Won-Kyu Park wrote: > > ... > > Could you please clarify "as expected"? > > It doesn't look like _fullpath() resolves symbolic links, which is expected > behaviour for $realpath_root. >
You are right but for most situations, translating a relative path to fullpath is enough, at least for me. (please see use case) > Rather, it looks like GetFinalPathNameByHandle() should be used if we want to > actually support $realpath_root as it is expected to work, that is, providing > path with symlinks resolved. It might > be tricky to use it though, as it is only available in Windows Vista or later. > > -- Maxim Dounin http://mdounin.ru/ yes. GetFinalPathNameByHandle() is not available in pre-Vista. full implementation might be preferred but this simple oneliner solve most use cases I guess. - win32/mingw32 only support _fullpath() - PHP7 use GetFinalPathNameByHandleW() ------------- use case: server { location / { root ../to/html; # works nicely without problem index index.php index.html index.htm; } location ~ \.php$ { root ../to/html; # not work. $realpath_root gives wrong value (c:\foobar\nginxroot\..\wiki), $document_root returns relative path # for this case, $realpath_root gives expected value with this _fullpath fix. #root c:/to/my/absolute/path/html; # works fine fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; # fix to use realpath_root #fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; # not work. fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name; # works fine with _fullpath fix. ... } } _______________________________________________ nginx-devel mailing list -- nginx-devel@nginx.org To unsubscribe send an email to nginx-devel-le...@nginx.org