-
Notifications
You must be signed in to change notification settings - Fork 361
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implementations of javalib fileKey
has at least two defects.
#3905
Comments
Very nice analysis 😄 |
Could someone who knows Windows check this out? I believe that The relevant code is (edited for presentation):
~~ I believe the simplest fix is to use a case class In the unix code, I decided to override |
fileKey
implementation of fileKey
has at least two defects.fileKey
has at least two defects.
fileKey
has at least two defects.fileKey
has at least two defects.
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:
dele
Given current definition, the test for equality uses reference (Object) equality rather thancontent 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.
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.Code exists, in two places, in
FilesTest
to fetch afileKey
. The is no test for the fetched value, a compilercould 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 ifthey 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
, andwalk()
describethe algorithm used by those two &
find()
to detectSystemFileSystemLoopException
. That algorithm uses anddepends upon content equal, unique
fileKey
s.And it is unshaven yaks all the way down...
The text was updated successfully, but these errors were encountered: