In general there is no protection against this, as Unix does not keep a canonical path for a file. (Shameless plug: See https://9p.io/sys/doc/lexnames.html.)

The test could perhaps find a safer solution but sysadmin creativity will eventually defeat it. Maybe use /etc? I don't know. Needs thought.

A suggestion:

• make a temp dir.
• chdir to the temp dir, compute Getwd. Keep for later below.
• make a sub-dir in the temp dir.
• make a symlink to the sub-dir.
• chdir to the symlink
• compute Getwd again.
• Check that the new Getwd is the expected sub-dir of the original result of Getwd (after symlink resolution).

Of course one can do that, but that depends on mkdir working, which if you think about it is a far higher bar than checking whether getwd is working. It's like proving the circle's circumference is 2πr using calculus.

And the proposed test only tests that it is consistent, not that it is correct. That's a lot of work for almost no information.

I'm not saying you're wrong, just that it's not a very good test. It may be hard to do better.

1. checking the relative consistency of getwd across directories and sub-directories is, IMHO, what applications care most about (that, together with the relative consistency of getwd and abspath)

2. There is another directory structure that's already there for you where you control the existence of symlinks: the go source tree itself. The test can check the consistency of getwd there without relying on mkdir.

The test is brittle, as discussed, but it can be strengthened by adding more directory test targets, then examining each one in the testing loop and skipping any that don't exist or contain symbolic links. I have revised test code that does this.

Change https://golang.org/cl/147777 mentions this issue: x/sys/unix: fix brittle test that contained dirs which might be symlinks, hence spuriously fail

Second try in the correct repo. I'll check the previous gerrit comments again to see if I addressed the feedback completely. golang/sys#22

Change https://golang.org/cl/148537 mentions this issue: unix: rework TestGetwdto hand test dirs whose names contain symlinks