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 · 16 comments

Comments

@networkimprov
Copy link

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

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

Copy link
Author

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

This comment has been minimized.

Copy link
Author

commented Jun 3, 2019

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

@odeke-em

This comment has been minimized.

Copy link
Member

commented Jun 23, 2019

Kindly pinging @jordanrh1 @alexbrainman

@alexbrainman

This comment has been minimized.

Copy link
Member

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

This comment has been minimized.

Copy link
Author

commented Jun 24, 2019

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

@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

Copy link
Author

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

This comment has been minimized.

Copy link
Member

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

This comment has been minimized.

Copy link
Author

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

This comment has been minimized.

Copy link
Member

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

This comment has been minimized.

Copy link
Author

commented Jul 3, 2019

@ianlancetaylor any thoughts on others to ping for this?

@odeke-em

This comment has been minimized.

Copy link
Member

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

This comment has been minimized.

Copy link
Author

commented Jul 3, 2019

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

@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

Copy link
Author

commented Sep 21, 2019

cc @zx2c4

@gopherbot add NeedsFix

@rsc rsc modified the milestones: Go1.14, Backlog Oct 9, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
9 participants
You can’t perform that action at this time.