On Thu, 26 Jun 2025, Jeremy Drake via Cygwin-developers wrote: > On Thu, 26 Jun 2025, Corinna Vinschen wrote: > > > On Jun 25 16:15, Jeremy Drake via Cygwin-developers wrote: > > > This turned out to be more complicated than I expected, > > > GetFileInformationByHandleEx(FileNameInfo) sucks badly, and seems to only > > > actually work for regular files. > > > > This is unexpected. GetFileInformationByHandleEx is basically just a > > wrapper for NtQueryInformationFile and that goes especially for the > > FileNameInfo class which even neglects to prepend a drive letter or > > UNC path to make the result useful in a DOS Path environment.
> > > Which is probably why Cygwin uses > > > NtQueryObject(ObjectNameInformation) instead, which I switched to > > > > Uh, we use NtQueryObject in cases where we want valid return values > > for real NT objects or device paths like \Device\Null. > > Sorry, I meant that it didn't work for handles to \Device\Null (or console > handles, but they are not part of the tests). I used /dev/null /dev/zero > and /dev/full in tests, and they all seem to turn into \Device\Null when > redirected to/from a Windows executable. I didn't try with directory > handles, because they didn't make sense in the context of redirecting > stdin/out/err. I guess I could add a test for that and see what the > result is (EISDIR?). Turns out Cygwin, Windows and Linux are fine with redirecting a directory handle/file descriptor to stdin. I guess any error would happen when the process tries to actually use it. > > > This > > > has the downside of giving NT native paths (\Device\HarddiskVolumeN\path). > > > > Downside? *grin* > > > > Downside for me because cygwin_conv_path doesn't produce such paths, > making it more difficult to pass the expected path to the child for > verification. It seems what I really wanted is GetFinalPathNameByHandleW, and then fall back to NtQueryObject if that fails. That allowed me to drop loading and calling into Cygwin dll.
