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

Comments

@networkimprov
Copy link

@networkimprov networkimprov commented May 29, 2019

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 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

@networkimprov networkimprov commented May 31, 2019

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.

@networkimprov
Copy link
Author

@networkimprov networkimprov commented Jun 3, 2019

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

@odeke-em
Copy link
Member

@odeke-em odeke-em commented Jun 23, 2019

Kindly pinging @jordanrh1 @alexbrainman

@alexbrainman
Copy link
Member

@alexbrainman alexbrainman commented Jun 24, 2019

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

@networkimprov networkimprov commented Jun 24, 2019

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

@ianlancetaylor
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Jun 24, 2019

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 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 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

@networkimprov networkimprov commented Jun 26, 2019

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 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

@networkimprov networkimprov commented Jul 3, 2019

@ianlancetaylor any thoughts on others to ping for this?

@odeke-em
Copy link
Member

@odeke-em 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

@networkimprov networkimprov commented Jul 3, 2019

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

@ianlancetaylor
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Jul 3, 2019

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 networkimprov commented Sep 21, 2019

@gopherbot add NeedsFix
@gopherbot add help wanted

@rsc rsc modified the milestones: Go1.14, Backlog Oct 9, 2019
@gopherbot
Copy link

@gopherbot gopherbot commented Nov 26, 2019

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
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
9 participants
You can’t perform that action at this time.