JDK-6371627 : (fc) IOException when trying to use FileChannel.lock on a file in ClearCase MVFS
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.nio
  • Affected Version: 1.4.2,5.0u6
  • Priority: P5
  • Status: Closed
  • Resolution: Not an Issue
  • OS: solaris_8,solaris_9
  • CPU: sparc
  • Submitted: 2006-01-12
  • Updated: 2011-02-16
  • Resolved: 2006-04-05
Related Reports
Duplicate :  
Relates :  
Description
FULL PRODUCT VERSION :
java version "1.4.2_10"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_10-b03)
Java HotSpot(TM) Client VM (build 1.4.2_10-b03, mixed mode)


ADDITIONAL OS VERSION INFORMATION :
SunOS <hostname omitted> 5.8 Generic_108528-24 sun4u sparc SUNW,Sun-Fire-V210


EXTRA RELEVANT SYSTEM CONFIGURATION :
> cleartool -ver
ClearCase version 2003.06.00 (Fri Apr 25 09:05:22 EDT 2003)
clearcase_p2003.06.00-19 (Tue Apr 05 22:23:24 EDT 2005)
clearcase_p2003.06.00-28 (Fri Nov 18 07:15:44 EST 2005)
clearcase_p2003.06.00-29 (Mon Nov 21 22:31:55 EST 2005)
@(#) MVFS version 2003.06.10+ (Fri Oct 28 16:28:10 2005)
cleartool                         2003.06.10+ (Sat Oct  1 00:17:54 EDT 2005)
db_server                         2003.06.10+ (Fri Sep 30 01:35:07 EDT 2005)
VOB database schema version: 53


A DESCRIPTION OF THE PROBLEM :
This bug is a regression from
java version "1.4.2"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28)
Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode)

When trying to use FileChannel.lock() on a file that resides within IBM/Rational ClearCase file system, I get IOException

Exception in thread "main" java.io.IOException: Invalid argument
        at sun.nio.ch.FileChannelImpl.lock0(Native Method)
        at sun.nio.ch.FileChannelImpl.lock(FileChannelImpl.java:750)
        at java.nio.channels.FileChannel.lock(FileChannel.java:865)
        at tests.TestLock.main(TestLock.java:34)

This resembles pretty much the bug #6230772, but the latter is claimed to be fixed in 1.4.2_10.

Reproduces on 1.4.2_04 as well.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Run the attached code when the current directory is inside a ClearCase view.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
No error should be seen
ACTUAL -
Exception in thread "main" java.io.IOException: Invalid argument
        at sun.nio.ch.FileChannelImpl.lock0(Native Method)
        at sun.nio.ch.FileChannelImpl.lock(FileChannelImpl.java:750)
        at java.nio.channels.FileChannel.lock(FileChannel.java:865)
        at tests.TestLock.main(TestLock.java:34)


ERROR MESSAGES/STACK TRACES THAT OCCUR :
Exception in thread "main" java.io.IOException: Invalid argument
        at sun.nio.ch.FileChannelImpl.lock0(Native Method)
        at sun.nio.ch.FileChannelImpl.lock(FileChannelImpl.java:750)
        at java.nio.channels.FileChannel.lock(FileChannel.java:865)
        at tests.TestLock.main(TestLock.java:34)


REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
package tests;

import java.io.File;
import java.io.FileOutputStream;
import java.io.IOException;

import java.nio.channels.FileLock;

public class TestLock {

    public static void main(String[] args) throws IOException {
        File file = new File("lock");
        FileOutputStream fos = new FileOutputStream(file);
        FileLock fileLock = fos.getChannel().lock();
        fileLock.release();
    }
}

---------- END SOURCE ----------
<moved>

Comments
WORK AROUND Use the lock(long,long,boolean) method instead of lock() and specify a position/size that is 2GB or less.
05-04-2006

EVALUATION -- This issue turns out to be a MVFS problem. It does not allow applications to obtain locks on files larger than 2GB. FileChannel's lock() and tryLock() methods are specified to lock the region (0-Long.MAX_VALUE). This works fine on ufs and nfs but with ClearCase's mvfs theF_SETLKW64 file control command to fail with EINVAL. The reason it appears to work prior to 1.4.2_10 is because the length was incorrectly truncated to a 32-bit value. That issue was fixed in 5.0 and backported to 1.4.2_10. Since there isn't anything further we can do on this issue I will close the bug.
05-04-2006

EVALUATION -- Update Feb 10, 2006: The submitter is anxious to track down the apparent regression in 1.4.2_10 and has provided additional information: 1. The output of ::fsinfo confirms that MVFS is indeed using the vfs framework. 2. A simple native program that uses fcntl's F_SETLKW64 command is working with this file system. So at this point we have conflicting data on this issue. The native program that uses F_SETLKW64 is working on this file system but that native program was derived from code in FileChannelImpl's locking code which isn't working. Clearly the issue is stems from the integration of 6230772 in 1.4.2_10 but that fixes
10-02-2006

EVALUATION -- The submitter provided the requested information: 1. The truss output shows that the fcntl F_SETLKW64 command is failing on ClearCase's MVFS but not on NFS. 2. The issue only happens with >= 1.4.2_10 (1.4.2_09 is okay). The issue also duplicates with 5.0u6. The only change to the file locking in 1.4.2_10 was 6230772. The lock position and size were previously truncated to an off_t when copying into the flock64 structure. With 6230772 fixed it means they are correctly copied as a off64_t. We probably need more information about mvfs to guess what is happening here. It would be great if the submitter can run "mdb -k" and use "::fsinfo" to see if mvfs is listed. If it is, then this means mvfs is going through the VFS layer. At a guess the issue may be a 32/64-bit issue in ClearCase mvfs implementation.
16-01-2006

EVALUATION We do not have a ClearCase MVFS environment readily available to investigate this issue. To help us, it would be great if the submitter could provide two additional pieces of information as this might actually be an issue with MVFS rather than J2SE. 1. truss output. 2. Has the submitter tried 5.0 or a latest Mustang snapshot to see if the issue has been fixed in a newer release?
12-01-2006