Redirecting stdin from a file in WSL and calling a Win32 executable causes GetFileSizeEx function to fail

[andrewluotechnologies]

Please see the attached for a reproducible code sample.

Running wslbug.exe < input.txt from Windows yields (the contents of input.txt don't matter, can even be empty):

1
Worked

From WSL:

1
GetFileSizeEx error 1

It appears that calling GetFileSizeEx on a stdin handle redirected from a file from WSL does not work properly. Error 1 means:

ERROR_INVALID_FUNCTION
1 (0x1)
Incorrect function.

Details of my environment:

uname -a: Linux DESKTOP 4.4.0-17763-Microsoft #194-Microsoft Mon Dec 03 17:58:00 PST 2018 x86_64 x86_64 x86_64 GNU/Linux
ver: Microsoft Windows [Version 10.0.17763.195]

wslbug.cpp.txt

[therealkenc]

I like it. You've hit a common pitfall, which exists in Linux too. Consider:

#include <unistd.h>
#include <iostream>
int main(int argc, const char *argv[])
{
    off_t sz = lseek(0, 0, SEEK_END);
    std::cout << "file size is: " << sz << "\n";
    return 0;
}

But...

Same problem. You aren't in your local shell anymore, and that < means something different in the two cases. The bug is in your program, insofar as it isn't remote shell friendly; just like my Linux program.

This said, I wish what you are trying to do worked. It would work with Cygwin. It could be made to work in WSL. But it would take a very big leap outside the box on how the devs look at the WSL project.

Don't have the heart to close by-design. Fun post, thanks.

[andrewluotechnologies]

I'm fine if this isn't supported/by-design but if that is the case, should GetFileType be returning FILE_TYPE_DISK? The documentation for GetFileSize (https://docs.microsoft.com/en-us/windows/desktop/api/fileapi/nf-fileapi-getfilesize) states:

You cannot use the GetFileSize function with a handle of a nonseeking device such as a pipe or a communications device. To determine the file type for hFile, use the GetFileType function.

Although it doesn't explicitly say what you can use it for, based on the exclusions, I was assuming if the type is FILE_TYPE_DISK, then you can get the size. I (personally) don't know of another other cases where you have a file of type FILE_TYPE_DISK but you can't call GetFileSize. It seems like another type would be more appropriate.

[therealkenc]

Appreciate the follow up. That's a good question. I didn't explore what that 1 in your OP was supposed to be trying to say. That is FILE_TYPE_DISK alright.

In that case, this issue seems legit. You put it clearly. However you define the correct behavior, the behavior needs to be one of either: (a) an actually seekable file handle or (b) not one. By being told FILE_TYPE_DISK you are left in the position where you can't test up front whether you should be calling GetFileSize(), and that ain't right.

[andrewluotechnologies]

I confirmed that this still occurs in a recent insider build:
uname -a:
Linux DESKTOP-HLO5ULF 4.4.0-18917-Microsoft #1000-Microsoft Fri Jun 07 19:42:00 PST 2019 x86_64 x86_64 x86_64 GNU/Linux

ver:
Microsoft Windows [Version 10.0.18917.1000]

The good news, however, is that this does work in WSL2. That said, it would be nice to have this fixed in WSL1 as well...

[microsoft-github-policy-service]

This issue has been automatically closed since it has not had any activity for the past year. If you're still experiencing this issue please re-file this as a new issue or feature request.

Thank you!