Comment 1:

Yes, please keep reporting these.

Labels changed: added priority-go1, removed priority-triage.

Owner changed to builder@golang.org.

Comment 2:

I can't reproduce.
More details?

Comment 3:

I am seeing this on windows.
Running "go test" in pkg/net/http leaves file named like C:\Documents and
Settings\brainman\Local Settings\Temp\067641025\foo.txt with "Hello world" inside. I
suspect it happens during TestFileServerImplicitLeadingSlash. If you check error
returned by os.RemoveAll(tempDir), you will see that sometimes it fails. File delete
will fail on Windows, if it is opened. You have no code that sync using foo.txt and
deleting it - so sometimes these two clash.
I know it is pain in the back, but that how it works. People who will run this test
might endup with new file like 067641025\foo.txt in their temp directory every time the
do that.
Alex

Comment 4:

That test starts like:
func TestFileServerImplicitLeadingSlash(t *testing.T) {
        tempDir, err := ioutil.TempDir("", "")
        if err != nil {
                t.Fatalf("TempDir: %v", err)
        }
        defer os.RemoveAll(tempDir)
        if err := ioutil.WriteFile(filepath.Join(tempDir, "foo.txt"), []byte("Hello world"), 0644); err != nil {
                t.Fatalf("WriteFile: %v", err)
        }
        ts := httptest.NewServer(StripPrefix("/bar/", FileServer(Dir(tempDir))))
        defer ts.Close()
The defer ts.Close() will run before the os.RemoveAll defer.  And all the HTTP requests
will be done by then.
So I'm confused.

Comment 5:

I didn't write that code, so it is hard for me to tell. But, as this issue demonstrates,
ts.Close completion does not guarantee that files are closed. If you think it is wrong,
then, I think, you have assumption somewhere in your code that does not stand.
You could try and see it for yourself. Alternatively, if you want me to try things, I
will do it. But you have to tell me what to check. I had quick look myself, but I am not
familiar with this code, so I got lost pretty quickly.
Alex

Comment 6:

I'm travelling without a Windows machine for a day.  But here's a CL which might be
helpful or interesting:
http://golang.org/cl/5707056

Comment 7:

I ran this:
for i in $(seq 1 30); do echo "go test >>/c/tmp/a.txt 2>&1" ; done| bash
the output is attached. Your CL (http://golang.org/cl/5707056) - your panic is
in the log. There are other problems, I see in the log. I didn't see them before.
Perhaps, they are there because I run test 30 times. I could look at these, if you
interested. :-)
Alex
$ hg id
b4580a3b3331+ tip

Attachments:

1. a.txt (229611 bytes)

Comment 8:

Are you running a virus scanner?
I'd put my money on a race between the test creating the file, virus scanner noticing
new file to scan, and the test deleting it.

Comment 9:

Nope. I do not run virus scanner. Many other tests create files in temp directory, but
they all get cleaned up. Not this one.
Alex

Comment 10:

I suspect this is a race between the server closing the file
(after serving the response) and the test trying to remove it
(after reading the response).
If the remove happens before the close, it will fail on Windows
but not on Unix.
The solution then would be to wait for the server to shut down,
or to insert a short sleep.

Comment 11:

Maybe http://golang.org/cl/5708066

Comment 12:

That does it. Thank you Brad.
Fixed by http://code.google.com/p/go/source/detail?r=8bdd36e45822.

Status changed to Fixed.