-
Notifications
You must be signed in to change notification settings - Fork 5.7k
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
5041655: (ch) FileLock: negative param and overflow issues #7254
Conversation
👋 Welcome back bpb! A progress list of the required criteria for merging this PR into |
Webrevs
|
If the javadoc is changed to document long standing behavior then the change would need to be normative, I don't think an impl note works here. I agree that throwing IAE is not an option. However, maybe you could try this:
|
|
It might be that checking if size <= 0 is enough. Maybe the starting point for this issue is a series of test cases with negative positions and sizes. All tests that uses a negative size should return false. The tests that use a negative position may overlap with the locked region. |
Never mind about #2: I know what you mean. |
I already wrote a test but it was not sufficiently cleaned up to include yet. |
…es; handle overflow; handle zero size on Windows; add test
Updates in commit 01:
|
/csr |
@bplb has indicated that a compatibility and specification (CSR) request is needed for this pull request. |
Changing the overlaps method to return false when size is negative is good. The updated range check that allows for the position to be negative looks good too. The compatibility impact should be negligible for this part. Changing the lock method to treat size==0 as Long.MAX_VALUE-position is the behavior on some platforms already and is implementable in a consistent way on all platforms. So on the surface it's probably the right thing to do. However as proposed, it creates a FileLock with size == 0 that will not overlap with any other lock. To work correctly, it will need to be "promoted" to Long.MAX_VALUE-position before creating the FileLock. That will allow you to drop the change to the native code from the patch. I have several comments on the javadoc changes but I think we need to get to agreement on size=0 first. |
I don't understand your comments about |
With the proposal, fc.lock(pos, 0L, shared) returns a FileLock where size() returns 0L. Can you try having this create a FileLock that reports its size as Long.MAX_VALUE - pos ? That should eliminate the inconsistencies in the proposal and the native code changes will go away too. |
I can change it as suggested. Note that the extant Unix version for size zero creates a lock where |
Right, so you end up with a FileLock that says it doesn't overlap with any other lock but it actually locks the region to the end of file. I think the inconsistencies will go if you promote 0 to MAX_VALUE-pos before create the FileLock object. |
I think that |
Commit 02: suggested source changes made; javadoc not yet changed. |
I think the change will be in FileChannelImpl.lock so that the same size is used to create the FileLock and passed through to the native dispatcher. |
Note that because of this code in the Unix
|
There should be no impact here. If someone calls fc.lock() then it's the equivalent of fc.lock(0, MAX_VALUE, false). The FileLock will be created with size=MAX_VALUE. The code above will just map it to 0 for the call to fcntl. |
e5d88e2
to
d1001cc
Compare
Thanks for the update, I think this change is on the right track now. For FileChannel.lock we'll need to come up with wording that precisely describes the behavior for the size==0 case. The issue with phrases like "remainder of the file" is that file may be extended after locking. The update to the FileLock protected constructors will need attention too. Extending FileLock and calling the constructor with size==0 doesn't align the proposed spec change (there is no connection to the native dispatching when creating a FileLock like this). I think it will work if you drop "A value of zero indicates the remainder of the file" from the javadoc. |
In the Unix version of
the check should be changed to
Similar question for |
CSR JDK-8281623 filed. |
src/java.base/share/classes/java/nio/channels/AsynchronousFileChannel.java
Outdated
Show resolved
Hide resolved
…MAX_VALUE - position
…ze zero yields size Long.MAX_VALUE - position
src/java.base/share/classes/sun/nio/ch/SimpleAsynchronousFileChannelImpl.java
Outdated
Show resolved
Hide resolved
@bplb This change now passes all automated pre-integration checks. ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details. After integration, the commit message for the final commit will be:
You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed. At the time when this comment was updated there had been 303 new commits pushed to the
As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details. ➡️ To integrate this PR with the above commit message to the |
/integrate |
Going to push as commit 6445ee4.
Your commit was automatically rebased without conflicts. |
Add an implementation note to
java.nio.channels.FileLock.overlaps(long,long)
indicating that the method does not check its parameters. Adding such checks would be an incompatible change.Progress
Issues
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.java.net/jdk pull/7254/head:pull/7254
$ git checkout pull/7254
Update a local copy of the PR:
$ git checkout pull/7254
$ git pull https://git.openjdk.java.net/jdk pull/7254/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 7254
View PR using the GUI difftool:
$ git pr show -t 7254
Using diff file
Download this PR as a diff file:
https://git.openjdk.java.net/jdk/pull/7254.diff