Implementations of javalib fileKey has at least two defects.

[LeeTibbert]

The implementation for javalib fileKey for unix-like (i.e. non-Windows) systems has at least two defects.
The Windows implementation appears to be OK. (Later: I think that Windows shares the problem of using
reference equality instead of content equality. See a separate entry below.)

Defects, at least:

1. dele Given current definition, the test for equality uses reference (Object) equality rather than
   content equality. This two fileKeys with should contain identical st_dev and st_ino will
   almost always compare not-equal, since they are almost assured to be different Objects.

   Later: Delete this concern. It is relevant to some interim development code, but not to the unix
   code in mainline. That code compares two unsigned long AnyVals (on 64 bit machine). I
   believe the compiler makes this a "content equals" check. When I changed to a two
   field Object, the "reference equal" .eq in ./nativelib/src/main/scala/scala/scalanative/runtime/Object.scala
   kicked in and hosed me.

             I do not know Windows very well, but I believe it to be a concern there (mainline uses a two field Object)
   

2. On Open Group 2018 (i.e. POSIX) , the pair (st_dev, st_ino) uniquely describes, per spec., a given file.
   The current SN uniximplementation currently uses only the st_ino, which may not be unique across devices,
   especially if st_ino contains a small integer.

3. Code exists, in two places, in FilesTest to fetch a fileKey. The is no test for the fetched value, a compiler
   could validly optimize away the call, so even the baseline "the .fileKey() code executes" is not assured.
   The returned pointer should be checked to be non-null.

   The contents of the de-referenced returned fileKey are opaque, so they can not be checked. Even if
   they could, determining the proper st_dev & st_ino for the check would be devo time consuming.

These defects have some impact. The JVM descriptions of java.nio.file.Files#walkFileTree, and walk() describe
the algorithm used by those two & find() to detect SystemFileSystemLoopException. That algorithm uses and
depends upon content equal, unique fileKeys.

And it is unshaven yaks all the way down...

[ekrich]

Very nice analysis 😄

[LeeTibbert]

Could someone who knows Windows check this out?

I believe that WindowsDosFileAttributeView.scala is using reference equality rather than content equality.

The relevant code is (edited for presentation):

       class DosFileKey(volumeId: DWord, fileIndex: ULargeInteger)

        private val dosFileKey =
          new DosFileKey(
            volumeId = fileInfo.volumeSerialNumber,
            fileIndex = fileInfo.fileIndex
          )


     
	def fileKey(): Object = dosFileKey  // Object equals is, I believe, reference equality.

~~ I believe the simplest fix is to use a case class class DosFileKey(volumeId: DWord, fileIndex: ULargeInteger).
That should generate equals & hashcode methods which override those in Object to give content equality.~~

In the unix code, I decided to override equals(), hashCode(), and toString()