You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The lock position is asked about rather than assumed
⚠️⚠️ AN ENVIRONMENT MAY EXPORT A NAME AND NOT IMPLEMENT WHAT IT NAMES.
This system locks a byte range, and the three continuous-integration rows that
run ON it measure that it does. A fourth row cross-builds and runs the result
under an EMULATOR of this system, which exports `NtLockFile' and answers
`STATUS_NOT_IMPLEMENTED' when it is called.
⭐ SO THE PROPERTY IS NOT A PROPERTY OF THE VOLUME, NOR OF THE FORMAT. It is a
property of what is beneath the program at the moment it asks. A word that
claimed the position regardless would be describing the INTERFACE rather than the
environment --- and the whole purpose of a capability word is that a caller may
ask before it calls and be told the truth about where it is.
⚠️ THE ENQUIRY IS MADE ON A DIRECTORY, WHICH IS NOT A THING THIS SYSTEM LOCKS,
and that is what makes it answerable without disturbing anything. A system that
implements the operation refuses a directory as a wrong request; one that has not
implemented it says so with a different value, and that difference is the whole
of the question. Nothing is locked either way, and it is asked once.
Measured under that emulator, through the C library above: a lock now reports
`ENOSYS' --- which is true there --- rather than the suite reporting four
observations that did not hold. On the three rows that run on the system itself,
nothing changes and the observations hold.
0 commit comments