JDK-6401919 : java.nio.channels.FileChannel.tryLock method call fails with an I/O exception
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.nio
  • Affected Version: 5.0u6
  • Priority: P2
  • Status: Closed
  • Resolution: Duplicate
  • OS: solaris_9
  • CPU: sparc
  • Submitted: 2006-03-22
  • Updated: 2010-04-02
  • Resolved: 2006-03-29
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
5.0u6Resolved
Related Reports
Duplicate :  
JDK-6371627 - (fc) IOException when trying to use FileChannel.lock on a file in ClearCase MVFS
Description
>     * Severity: Significant impact on primary functionality
>     * Short description: Sometimes the java.nio.channels.FileChannel.tryLock method call fails with an I/O exception with the error message ?Invalid argument?
>     * Primary design contact: Norbert  Ghersin, ###@###.###, 613-763-8788
>     * Full problem description:
>
>  I have run into a JDK bug with identical symptoms as bug 6230772 (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6230772). The latter was reported against JDK 1.4.2_07 on Linux.
>
> When running the following code (see test-case) against some files it fails with an I/O exception with error message ?Invalid argument?. Since the bug description for 6230772 includes the output of running the ?truss? command, I have the truss output file (truss_output).

> The command I ran was: ?truss java F?
>
> I am not sure about why this file (or any file within the same directory fails), but it may be because it is on a different disk partition. I even tried running the test against other folders on the failing partition and it did not work. The files I tried to lock were created, could be delete but locking failed.
>
> Here are the results of some runs:
>   ~/temp F /opt/cems/blah
> java.io.IOException: Invalid argument
> Unable to acquire lock!
> /opt/cems> ls -l /opt/cems/blah
> -rw-rw-r--   1 nghersin cellone        0 Mar  1 21:30 /opt/cems/blah
> /opt/cems> df -k .
> Filesystem            kbytes    used   avail capacity  Mounted on
> /net/zcars0xz/export/vobstore/disk2/cdma_bssm/cems.vbs
>
                     77750272 63620609 13289426    83%    /vobs/cems
>
> java -classpath ~/temp F ~/blah
>
> Successfully locked file
>
> /opt/cems> ls -l ~/blah
>
> -rw-rw-r--   1 nghersin cellone        0 Mar  1 21:35 /home/nghersin/blah
>
> /opt/cems> df -k ~
>
> Filesystem            kbytes    used   avail capacity  Mounted on
>
> zcareb60:/export/users/car411/nghersin
>
>                      79508336 42631024 36877312    54%    /home/nghersin

> We still see the same locking failure problem at our end.  This time I repeated the test with 3 java versions that is available in our environment:
>  java version ?1.4.2_06?
>  java version ?1.5.0_02?
>  java version ?1.5.0_04?
>
> Interestingly, java version 1.4.2_06 is successful in obtaining locks in both disk partitions, while 1.5.0_02 and 1.5.0_04 failed in one of them (same as originally reported).

> <vob> [temp]=105=> /vobs/cems/thirdparty/j2se/solaris/bin/javac F.java
> <vob> [temp]=106=> /vobs/cems/thirdparty/j2se/solaris/bin/java -classpath ~/temp F /opt/cems/blah
> Successfully locked file
> <vob> [temp]=107=>  /vobs/cems/thirdparty/j2se/solaris/bin/java -classpath ~/temp F ~/blah
> Successfully locked file
> <vob> [temp]=108=>  /vobs/cems/thirdparty/j2se/solaris/bin/java -version
> java version "1.4.2_06"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_06-b03)
> Java HotSpot(TM) Client VM (build 1.4.2_06-b03, mixed mode)
> <vob> [temp]=109=>
> <vob> [temp]=109=>
> <vob> [temp]=109=>  /vobs/cems/thirdparty/jdk1.5.0_02/solaris/bin/javac F.java
> <vob> [temp]=110=>  /vobs/cems/thirdparty/jdk1.5.0_02/solaris/bin/java -classpath ~/temp F /opt/cems/blah
> java.io.IOException: Invalid argument
> Unable to acquire lock!
> <vob> [temp]=111=> /vobs/cems/thirdparty/jdk1.5.0_02/solaris/bin/java -classpath ~/temp F ~/blah
> Successfully locked file
> <vob> [temp]=112=>  /vobs/cems/thirdparty/jdk1.5.0_02/solaris/bin/java -version
> java version "1.5.0_02"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_02-b09)
> Java HotSpot(TM) Client VM (build 1.5.0_02-b09, mixed mode)
> <vob> [temp]=113=>
> <vob> [temp]=113=>
> <vob> [temp]=113=> /vobs/cems/thirdparty/jdk1.5.0_04/solaris/bin/javac F.java
> <vob> [temp]=114=>  /vobs/cems/thirdparty/jdk1.5.0_04/solaris/bin/java -classpath ~/temp F /opt/cems/blah
> java.io.IOException: Invalid argument
> Unable to acquire lock!
> <vob> [temp]=115=>  /vobs/cems/thirdparty/jdk1.5.0_04/solaris/bin/java -classpath ~/temp F ~/blah
> Successfully locked file
> <vob> [temp]=116=> /vobs/cems/thirdparty/jdk1.5.0_04/solaris/bin/java -version
> java version "1.5.0_04"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_04-b05)
> Java HotSpot(TM) Client VM (build 1.5.0_04-b05, mixed mode)

And the problem is seen  on a different machine as well.

* Test Case Attached with this CR *

Step to run the test case :
   Run the Java file along with the Path of the file residing in a different partition in command line argument
Comments
EVALUATION -- The submitter has obtained further information from the customer: "Locking fails for any file in a ClearCase view (file system is MVFS) and succeeds for any file in a UNIX view." We are tracking that issue as 6371627 so I will close this bug as a duplicate.
29-03-2006
EVALUATION -- Submitter has been contacted seeking further information on this failure.
26-03-2006
EVALUATION This may be the same issue as 6371627. If the submitter is able to duplicate the issue on a system inside of Sun then please mail me the host details so that we can examine the issue.
22-03-2006