It's not necessary that it works for symlinks too (though, of course, it would be nice).

Wrong. It must work for symlinks or it will easily break on non-windows systems. Normalising paths with symlinks is relatively easy.

In Java, there is a function JavaFileManager.isSameFile, which performs exactly this function

I don't think so. JavaFileManager is an interface, not a class. No code, just conventions. And by the way, JavaFileManager.isSameFile() is a method, not a function. It would require a lot of knowledge about the underlying operating system and the used filesystems. And it would get really complicated with files on network file systems.

From the documentation at http://download.oracle.com/javase/6/docs/api/javax/tools/JavaFileManager.html#isSameFile%28javax.tools.FileObject,%20javax.tools.FileObject%29:

isSameFile

boolean isSameFile(FileObject a,
                   FileObject b)

    Compares two file objects and return true if they represent the sa
+me underlying object.

    Parameters:
        a - a file object
        b - a file object 
    Returns:
        true if the given file objects represent the same underlying o
+bject 
    Throws:
        IllegalArgumentException - if either of the arguments were cre
+ated with another file manager and this file manager does not support
+ foreign file objects
[download]

The method compares objects, not files. It may throw an exception when the objects weren't created by the same file manager, giving you no useful information at all.

The interface makes no statement about network file systems. What happens when a filesystem is mounted in two different places, e.g. /mnt/a and /mnt/b? Will the method detect that /mnt/a/foo and /mnt/b/foo are the same file? Even if /mnt/a is a directory exported via NFS from one server and /mnt/b is the same directory exported via CIFS from the same server? Even if the NFS server and the CIFS server use different names, different network interfaces and different addresses?

Another problem is that each part of the filename may be case sensitive, case preserving, or case insensitive, depending on the filesystems. File::Spec does not take that problem into account and assumes, for example, that all filenames on Unix derivates are always case sensitive (see Re^5: Unify windows filenames).

So whenever you cross a filesystem border, the rules for normalising and comparing may change, depending on the filesystem itself and the mount options.

Regarding the Windows API, Re: Detecting whether two pathes refer to the same file shows you a way to handle local NTFS systems. I don't know how Windows handles files on other file systems. Does it emulate the NTFS IDs like Linux does when it mounts a FAT file systems? What about ISO9660 (CDROM) and UDF (DVD)? What about network filesystems?

Alexander