On Jun 26 13:26, Jeremy Drake via Cygwin-developers wrote: > 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.
Yes, that's by design. That way you at least have some handle to pass to a native process. > > 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. Whatever error occurs, it's not disallowed to redirect stdio to any descriptor/handle. It's the job of the process the handles get passed to to know what to do with them and if they don't know... *shrug* user error. > > > > > 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. Yeah, GetFinalPathNameByHandleW is actually pretty nice. Corinna
