os: consider syscall.EEXIST in os.IsExist

[bep]

Note that I'm not very categorical in my issue title, but this debugging of a subtle Afero file system bug has given me enough gray hairs to at least deserve an issue/discussion.

The program below runs fine on *nix but fails on Windows (it compiles fine):

package main

import (
	"log"
	"os"
	"syscall"
)

func main() {
	if !os.IsExist(syscall.EEXIST) {
		log.Fatal("failed")
	}
}

I assume that syscall.EEXIST will never happen on Windows, and then it should probably also not be defined for Windows. I guess that ship has sailed, but you should then consider to expand os.IsExist on Windows to also include this error. Because there may be other people creating file system abstractions that can be bitten by this.

/cc @spf13

[alexbrainman]

I assume that syscall.EEXIST will never happen on Windows,

syscall.EEXIST will never happen on Windows,

and then it should probably also not be defined for Windows.

It should not be defined on Windows.

As far as I remember (I could be wrong), when first Windows version of Go appeared, we copied modified UNIX version of syscall package to make all other packages work. And only later we started writing Windows code in packages other than syscall.

I guess that ship has sailed,

Maybe we can remove these symbols in Go 2. Whatever Go 2 is.

but you should then consider to expand os.IsExist on Windows to also include this error. Because there may be other people creating file system abstractions that can be bitten by this.

I don't see syscall.EEXIST used under $GOROOT on Windows. I doubt anyone uses syscall.EEXIST on Windows. I think, expanding os.IsExist to include syscall.EEXIST will confuse this matter even more. I think we should leave it alone.

syscall package is platform specific. You cannot assume that syscall.EEXIST will behave one way or the other on Windows.

Alex

[bep]

I doubt anyone uses syscall.EEXIST on Windows.

I linked to a widely used example in my issue report:

spf13/afero@5e9f8ec

[alexbrainman]

I doubt anyone uses syscall.EEXIST on Windows.

I linked to a widely used example in my issue report:

Fair enough. I take my word about "anyone uses syscall.EEXIST on Windows". But my point still stands - you assumed things about syscall.EEXIST that were never there. You fixed your code. I don't think there is anything else to do.

Alex

[bep]

you assumed things about syscall.EEXIST that were never there.

Let me be clear: This is not my code. I fixed some other person's code. And the repository I linked to is owned by a person that happens to also be on the Go team at Google -- which may indicate that this is a mistake that is a little bit too easy to make.

[alexbrainman]

And the repository I linked to is owned by a person that happens to also be on the Go team at Google -- which may indicate that this is a mistake that is a little bit too easy to make.

Everyone makes mistakes. Only people who don't write code do not make mistakes.

The person who wrote the code, should not have used syscall.EEXIST on Windows. That is the mistake here as far as I am concerned. How do you propose to stop feature developers to use syscall.EEXIST on Windows by changing os.IsExist?

Alex

[networkimprov]

@bep you could propose a documentation change to warn readers about this...

[spf13]

This sounds to me like a documentation change needs to be made. I'm the one who wrote the offending code originally. If there were better docs, I wouldn't have.

…

On Mon, Dec 17, 2018 at 2:24 PM Liam ***@***.***> wrote: @bep <https://github.com/bep> you could propose a documentation change to warn readers about this... — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#29295 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAKlZO8lrArEd93EwRBb4Im7poXyO_Jaks5u5--BgaJpZM4ZVMKy> .

[ianlancetaylor]

It doesn't seem so bad to me to have os.IsExist accept syscall.EEXIST on Windows. It may have been a mistake to define syscall.EEXIST at all on Windows. But once we made that mistake, it seems that we may as well carry it forward to functions like os.IsExist, for precisely this reason: because some code that runs on Windows may start using it.

[alexbrainman]

This sounds to me like a documentation change needs to be made.

Any documentation sounds good to me. I just do not know what to say - Do not use EEXIST!? It would require some explanation of why not to use.

But once we made that mistake, it seems that we may as well carry it forward to functions like os.IsExist, for precisely this reason: because some code that runs on Windows may start using it.

I do not see reason for syscall.EEXIST to be used on Windows. So I believe code with syscall.EEXIST is broken. I don't see how making os.IsExist(syscall.EEXIST) return true helps in this situation.

What would the code that uses syscall.EEXIST would look like?

Alex

[ianlancetaylor]

The code that uses syscall.EEXIST would look like

// Special purpose file system layer available on both Unix and Windows.
func (mfs *MyFileSystem) Open(path string) (*MyFile, error) {
    if mfs.noSuchPath(path) {
        return nil, syscall.EEXIST // this error is available on both Unix and WIndows
    }
    ...
}