GH-118447: Fix handling of unreadable symlinks in os.path.realpath()

[barneygale]

• Issue: posixpath.realpath('secretlink') raises #118447

[barneygale]

If not resolving unreadable symlinks is acceptable, you still need to raise an error for link/...

realpath() shouldn't raise OSError in non-strict mode.

[serhiy-storchaka]

Why not keep os.stat(newpath) here?

[barneygale]

For consistency with the way we raise NotADirectoryError in #118290, and to save the small cost of a stat()

[serhiy-storchaka]

Is it needed? How does the test work on Windows?

[barneygale]

It won't work on Windows because ABSTFN is an absolute path with backslash separators. These decorators are also used for other tests in this suite.

[serhiy-storchaka]

Please test also cases where non-readable symlink is followed by other path components (including ..), e.g. badlink/foo, badlink/../foo, badlink/foo/.., etc.

If the following .. removes badlink, try to test something that involves a loop containing badlink, if this is possible. Your code does not set seen[newpath] = None before calling readlink(), I wonder what effect does it have.

[nineteendo]

Suggested change

	self.assertEqual(realpath(ABSTFN), ABSTFN)
	self.assertEqual(realpath(ABSTFN), ABSTFN)
	self.assertEqual(realpath(ABSTFN + '/foo'), ABSTFN + '/foo')
	self.assertEqual(realpath(ABSTFN + '/../foo'), dirname(ABSTFN) + '/foo')
	self.assertEqual(realpath(ABSTFN + '/foo/..'), ABSTFN)

[nineteendo]

OK, you're right, it shouldn't raise an error. That's what strict is for.

[serhiy-storchaka]

I think that it is reasonable to expect that realpath('dir/badlink/rest') returns the same result when badlink does not exist, is a file, is in non-readable directory or is non-readable itself, for any rest. It's error prone, but that's how it was defined.