Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

syscall: Windows Errno constants invalid #32309

Open
networkimprov opened this issue May 29, 2019 · 17 comments
Open

syscall: Windows Errno constants invalid #32309

networkimprov opened this issue May 29, 2019 · 17 comments
Labels
help wanted NeedsFix The path to resolution is known, but the work has not been done. OS-Windows
Milestone

Comments

@networkimprov
Copy link

These constants: https://golang.org/src/syscall/types_windows.go#L7

Should appear in these constants: https://golang.org/src/syscall/zerrors_windows.go#L16

... because the latter are currently useless for comparison with Errno values, unlike other supported OSes. For example err.(*os.PathError).Err == syscall.ENOTEMPTY is never true on Windows.

Filed at request of @rsc

@gopherbot add OS-Windows

@ianlancetaylor ianlancetaylor added this to the Go1.13 milestone May 29, 2019
@rsc
Copy link
Contributor

rsc commented May 31, 2019

There do exist fake windows syscall Errnos. They won't go away entirely. But the fakes should only be used for traditional Unix errors that don't exist in Windows world. For example ENOENT and ENOTDIR already map to real windows errors instead of being provided by fakes. In the same way, ENOTEMPTY should map to ERROR_DIR_NOT_EMPTY. Perhaps there are others too. But to be clear, some (many) of the fakes will remain.

@networkimprov
Copy link
Author

I'm unclear why each Errno that cannot appear on windows has a unique value. I would expect them to share a value, e.g. 0xbad5eed.

@julieqiu julieqiu added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Jun 1, 2019
@networkimprov
Copy link
Author

I think we're at NeedsFix here... Should this be assigned to someone?

@odeke-em
Copy link
Member

Kindly pinging @jordanrh1 @alexbrainman

@alexbrainman
Copy link
Member

Sure, I am happy to investigate. But I don't understand what the problem is. @networkimprov, please, try again.

Thank you.

Alex

@networkimprov
Copy link
Author

@rsc or @ianlancetaylor, could you suggest a course of action?

@ianlancetaylor
Copy link
Contributor

In zerrors_windows.go ENOENT and ENOTDIR are set to the values of Windows errors defined in types_windows.go. Then zerrors_windows.go has a list of other invented error values. For each invented error value in zerrors_windows.go we should check whether there is a defined Windows error value in types_windows.go with the same meaning. If there is, we should move that entry in zerrors_windows.go up to the ENOENT and ENOTDIR group, and set it to the appropriate value in types_windows.go.

@networkimprov
Copy link
Author

networkimprov commented Jun 26, 2019

Also the top comment re "mkerrors_windows.sh" should be removed, and maybe the file renamed, since it's no longer script-generated.

Any takers? This is tagged for 1.13.
cc @mattn

@mattn
Copy link
Member

mattn commented Jun 26, 2019

I know some error constants or signal types are fake on Windows. IMO, the fake errors on Windows is required to implement using runtime.GOOS.

if runtime.GOOS == "windows" {
  // do windows specific
} else {
  if err == syscall.ENOTEMPTY {
  }
}

As you know, we can separate this code to per OS's files with build constraints. However, we should provide simple way to write code.

@networkimprov
Copy link
Author

I don't follow you. Did you see Ian's request? #32309 (comment)

This set: https://golang.org/src/syscall/zerrors_windows.go#L6
needs more of these: https://golang.org/src/syscall/types_windows.go#L7
For example ENOTEMPTY.

@mattn
Copy link
Member

mattn commented Jun 26, 2019

I just meant that it must not be removed. For about values of the UNIXish constaint, because it is OS specific valuse, that should be set same value defined in header file of mingw compiler.

Additional

I'm not sure, I don't think that all of UNIX constaint values can be mapped to Windows constaint.

@networkimprov
Copy link
Author

@ianlancetaylor any thoughts on others to ping for this?

@odeke-em
Copy link
Member

odeke-em commented Jul 3, 2019

@networkimprov, please feel free to send a CL fixing this but otherwise Ian and others also have a lot on their plates, moreover right before Gophercon and with Go1.3 about to be released so the pings might be perceived as pressure.

@networkimprov
Copy link
Author

Sorry... Ian tagged it 1.13; I wouldn't have asked otherwise.

@ianlancetaylor
Copy link
Contributor

Thanks. I don't think there is anything new here. If nobody sends in a CL shortly, we'll kick it to 1.14.

@andybons andybons modified the milestones: Go1.13, Go1.14 Jul 8, 2019
@networkimprov
Copy link
Author

networkimprov commented Sep 21, 2019

@gopherbot add NeedsFix
@gopherbot add help wanted

@gopherbot gopherbot added NeedsFix The path to resolution is known, but the work has not been done. and removed NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels Sep 21, 2019
@rsc rsc modified the milestones: Go1.14, Backlog Oct 9, 2019
@gopherbot
Copy link

Change https://golang.org/cl/208537 mentions this issue: syscall: remove ENFILE error code for Windows

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted NeedsFix The path to resolution is known, but the work has not been done. OS-Windows
Projects
None yet
Development

No branches or pull requests

9 participants