Message9798

Sorry 'bout that, I've taken a deeper look.

I conclude that we cannot pass both the tests now failing on OS X, and the tests that were failing on Windows, as long as we use Path.toRealPath() uniformly. The issue is with the treatment of alternate (DOS 8.3) names on Windows. On Windows, CPython (2.8 and 3.4) does this:
>>> os.path.realpath('junk\PROGRA~1')
'C:\\Users\\Jeff\\Documents\\Jython\\2.7rc2\\junk\\PROGRA~1'
>>> os.chdir('junk\PROGRA~1')
>>> os.getcwd()
'C:\\Users\\Jeff\\Documents\\Jython\\2.7rc2\\junk\\PROGRA~1'

On Windows, java.nio.files does this:
>>> Paths.get('junk\PROGRA~1').toRealPath()
C:\Users\Jeff\Documents\Jython\2.7rc2\junk\Program Files
>>> Paths.get('junk\PROGRA~1').toAbsolutePath()
C:\Users\Jeff\Documents\Jython\2.7rc2\junk\PROGRA~1

So Java resolves PROGRA~1 to its full NT name, whereas CPython maintains the 8.3 name it was given.

On Linux I find that os.path.realpath resolves symbolic links (as required) but not hard links, which is also the behaviour of Java Path.toRealPath(). Is PROGRA~1 a sort of hard link, then?

It seems as if CPython os.chdir calls os.path.realpath (although I can't track that down). On Windows, os.path = ntpath and realpath is just abspath, which is not required resolve symbolic links. CPython ntpath.abspath calls nt._getfullpathname, but that doesn't resolve the 8.3 name to its NT name:
>>> nt._getfullpathname('junk\PROGRA~1')
'C:\\Users\\Jeff\\Documents\\Jython\\2.7rc2\\junk\\PROGRA~1'

Internally, CPython nt._getfullpathname involves the MS function GetFullPathName, which Java also uses in WindowsLinkSupport.getRealPath. While I'm still puzzled by the difference in result between ntpath and java.nio.file, it seems clear we have to make them agree on Windows as they do on Linux.