I am one of the net/webdav developers. I can look into this but I do not have access to a Plan9 system. Is there some build machine available to run test code?

I can get you trybot access. Email me your Gerrit email address.

@bradfitz Sent you a private mail @golang

@bradfitz @mikioh Most probably I am doing something wrong, but I can't get the trybot to run my test CL, despite the Run-TryBot+1 label. The CL is here https://go-review.googlesource.com/#/c/11782 and I set the Run-TryBot label almost two hours ago.

Maybe it doesn't work because of the DO NOT REVIEW comment? Sorry to bother you, I just couldn't find much info on how to use this except for looking at other CLs.

Until the trybots start working with the x/net subrepo, I'll have to postpone debugging of this issue.

If it is critical to get this working again ASAP, I suggest to hand this over to someone with a Plan9 system; I'll be happy to assist then. Alternatively, if someone provides me with a ready-to-use Plan9 ISO that works with Parallels or SSH access to a Plan9 machine I can debug as well. Thanks.

@rsto Don't worry, I'll investigate this issue on my side.

@0intro thanks.

FYI, on a high level this is what happens in the currently broken test case:

- create a directory with ioutil.Tempdir, then create an arbitrary, 
  regular file in it, called "a".
- Then try to mkdir a directory named "a" in the same temporary 
  directory and assert that the returned error is os.IsErrExist. 

The test currently fails, since somewhere along the call chain there is a nil error returned instead. Of course there could be anything to blame, including the test code (which works on other systems, though).

This issue is not specific to the x/net/webdav package.
It seems to be a bug in the os or syscall package.

Here is an example to reproduce it using the os package:

http://play.golang.org/p/m3hhhvBxA7

So I guess its better to open a new issue for that? One additional data point: this bug could have sneaked in recently, since this test case hasn't been touched for at least the last three months or so. I don't know how often the buildbots run, though.

In fact, on Plan 9, the create syscall doesn't return an error when creating a directory
when a file with the same name already exists.

The mkdir command calls the access function from the libc
to check if the file already exists, before calling create.

https://github.com/0intro/plan9/blob/d1d89ac329/sys/src/cmd/mkdir.c#L19

The access function calls dirstats to check if the file already exists.

https://github.com/0intro/plan9/blob/c0f3d9569e/sys/src/libc/9sys/access.c#L21

Maybe we should implement the same logic for os.Mkdir on Plan 9.

So I guess its better to open a new issue for that?

I believe it's fine here, so we have everything in the same place.

One additional data point: this bug could have sneaked in recently, since this test case hasn't been touched for at least the last three months or so. I don't know how often the buildbots run, though.

As far I can tell, this issue has been present for months.