Hi Oleg, Thanks for the proposed patch.
Regarding the motivation, i.e.: What is wrong with the existing code? > GetFinalPathNameByHandle canonicalizes the path of an open handle, which > costs a round trip into the file system for every file that is stat'ed. > Only the file name suffix is needed here, and GetFileInformationByHandleEx > with argument FileNameInfo answers from the handle itself. If I understand it correctly, you say that the existing code is slower than needed. I'm more worried about correctness than about speed. What about files that are native Windows symlinks, created through 'mklink' [1]? I mean, if we have a link foo -> bar.exe the function stat() [as opposed to lstat()] is supposed to find the suffix ".exe" and thus return an "executable bit" in the mode. The documentation of GetFinalPathNameByHandleA says that it resolves symbolic links; the documentation of GetFileInformationByHandleEx doesn't. Then, regarding the patch: I think it uses the WideCharToMultiByte function [2] incorrectly. A second argument of 0 is almost never what you want. Actually, you could remove that WideCharToMultiByte call. Testing for a .exe suffix should be possible at the WCHAR[] level already. Bruno [1] https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/mklink [2] https://learn.microsoft.com/en-us/windows/win32/api/stringapiset/nf-stringapiset-widechartomultibyte
