HI Shengjing, On Thu, Aug 2, 2018 at 8:49 AM, Shengjing Zhu <i...@zhsj.me> wrote: > Hi Go team, > > On Tue, Jun 26, 2018 at 10:52:52PM +0000, Santiago Vila wrote: >> === RUN TestExecutableDelete >> --- FAIL: TestExecutableDelete (0.00s) >> osext_test.go:135: Child returned >> "/tmp/go-build962600465/b001/osext.test (deleted)", not the same file as >> "/tmp/go-build962600465/b001/osext.test" >> FAIL >> FAIL github.com/kardianos/osext 0.004s >> > > I think this test doesn't make any sense, we should just skip this test.
That would be the _pragmatic_ thing to do, especially when several packages still depends on this package, but... > Reading this test logic, it first reads its self executable path, then > start it self, then remove original file. It of cause prints the > "/tmp/go-buildnnn/b001/osext.test (deleted)". > ^^^^^^^^^ Well, yes and no... this error is intermittent (random?), and on Debian CI and Ubuntu Autopkgtest, the test _usually_ passes: * https://ci.debian.net/packages/g/golang-github-kardianos-osext/unstable/amd64/ * https://autopkgtest.ubuntu.com/packages/golang-github-kardianos-osext The corresponding GitHub issue at https://github.com/kardianos/osext/issues/21 hints at a possible race condition in the test. For some reasons, however, I have been unable to reproduce this test FAIL on my own machine. > Besides in go >= 1.8, this package's Executable function just fallback > to go system os package. So, yes, skipping TestExecutableDelete is the entirely pragmatic thing to do, but there is this little voice in my gut urging me to learn to diagnose what exactly triggers this intermittent test failure, and if it is indeed a race condition, how to fix it? :-) Cheers, Anthony
