os: Stdin.Stat() doesn't work on Windows

[mattn]

1. What version of Go are you using (go version)?

   tip

2. What operating system and processor architecture are you using (go env)?

   windows/amd64

3. What did you do?

   http://play.golang.org/p/1Ey_cU8qb_

4. What did you expect to see?

   No error occurd.

5. What did you see instead?

   GetFileInformationByHandle /dev/stdin: The handle is invalid.
   exit status 2
   

[mattn]

diff --git a/src/os/stat_windows.go b/src/os/stat_windows.go
index d65c582..fb75c3f 100644
--- a/src/os/stat_windows.go
+++ b/src/os/stat_windows.go
@@ -25,6 +25,9 @@ func (file *File) Stat() (FileInfo, error) {
    if file.name == DevNull {
        return &devNullStat, nil
    }
+   if file.name == Stdin.name || file.name == Stdout.name || file.name == Stderr.name {
+       return &fileStat{name: basename(file.name)}, nil
+   }
    var d syscall.ByHandleFileInformation
    e := syscall.GetFileInformationByHandle(syscall.Handle(file.fd), &d)
    if e != nil {

This may fix

[gopherbot]

CL https://golang.org/cl/20845 mentions this issue.

[hirochachacha]

Hi, I tried to reproduce this. But I couldn't.
Here are my compiler versions.
go version go1.5.2 windows/amd64
go version devel +53efe1e Wed Mar 23 11:33:29 2016 +0000 windows/amd64
Both of them are on windows 10.
And they produced same output without errors:

-rw-rw-rw-

Did you already tried it by different compiler version?

[mattn]

Are you trying this on msys2, cygwin or something like unix-shell?

[hirochachacha]

I tried it on msys2, and confirmed the issue on cmd.exe now. Thanks.

[alexbrainman]

Hi, I tried to reproduce this. But I couldn't.

I am not surprised. The problem here is that calling GetFileInformationByHandle on stdin handle fails sometimes. I don't see why GetFileInformationByHandle should succeed here - stdin is not a file, so GetFileInformationByHandle wouldn't have anything interesting to say about it. But Windows 10 implementation might have different ideas.

I think we should fix this by not calling GetFileInformationByHandle on stdin, stdout and stderr, and returning something reasonable.

Alex

[treeder]

I'm getting this still with Go 1.7.3 on Windows 10. This works on Linux.

PS C:\...\tmp>o version
go version go1.7.3 windows/amd64
PS C:\...\tmp> go run .\main.go
2016/11/12 22:58:55 GetFileInformationByHandle /dev/stdin: Incorrect function.
exit status 1

main.go:

package main

import (
    "log"
    "os"
)

func main() {
    _, err := os.Stdin.Stat()
    if err != nil {
        log.Fatalln(err)
    }
}

[treeder]

Looks like this doesn't error if you pipe something in, eg:

PS C:\...\tmp> go run .\main.go            
2016/11/12 23:08:52 GetFileInformationByHandle /dev/stdin: Incorrect function.                 
exit status 1                                                                                      
PS C:\...\tmp> echo "hi" | go run .\main.go  
PS C:\...\tmp> 

[alexbrainman]

I'm getting this still with Go 1.7.3 on Windows 10

Yes. I can reproduce that too. Thank you very much.

It seems, when you apply syscall.GetFileType to stdin file descriptor, it returns FILE_TYPE_CHAR. We should add code similar to FILE_TYPE_PIPE to handle this scenario. FILE_TYPE_CHAR can be mapped into os.ModeCharDevice. Unfortunately we won't be able to test any of that, because we need real console to reproduce this.

Alex

[gopherbot]

CL https://golang.org/cl/34090 mentions this issue.

[ALTree]

Something is wrong here: this issue is 1) open 2) assigned to a closed milestone (go1.7).

Someone with access to a windows machine should try to reproduce the problem with go1.8 and then change the milestone (or close the issue), according to the result.

Conservatively moving to go1.9, for now.

[alexbrainman]

Something is wrong here: this issue is 1) open 2) assigned to a closed milestone (go1.7).

Sorry. I have reopened old issue, but did not changed milestone.

Someone with access to a windows machine should try to reproduce the problem with go1.8

I can reproduce the problem with go1.8.

and then change the milestone (or close the issue), according to the result.

The issue milestone is go1.9, and that sounds fine to me. There is a fix https://golang.org/cl/34090 waiting to be reviewed once Go source tree opens after release.

Alex