confused abt FileLock behavior

Discussion in 'Java' started by David Zimmerman, Jul 28, 2003.

  1. VX wrote:
    > I have a question about the new FileLock functionality in java.nio packages.
    >
    > I wrote a little test code like this
    >
    >
    > FileInputStream f=new FileInputStream("xyz.txt");
    > FileChannel fc=f.getChannel();
    > System.out.println("The size of the file is: " + fc.size() );
    >
    > //now the file lock
    > FileLock lock=fc.lock(); //***this is suppose to lock the entire file
    > System.out.println("The size of the lock is: " + lock.size());
    >
    > Now here is the the problem. the size given by FileChannel is about 306
    > bytes (which is ok). ***But the size give by the lock is 9007199254740991
    > bytes!!!
    >
    > I also checked the API docs...here is what it says
    > size
    > public final long size()Returns the size of the locked region in bytes.
    > A locked region need not be contained within, or even overlap, the actual
    > underlying file, so the value returned by this method may exceed the file's
    > current size.
    >
    >
    >
    > Returns:
    > The size of the locked region
    > Here are my questions:
    > 1: Does this means that my lock has locked a region of 9007199254740991
    > bytes. What will happen to any other file saved in that region?
    > 2:What is this locked region if it doesnt 'contained within or even overlap
    > with the actual underlying file' ?
    > 3: why should the lock size exceed the current file size. What is the
    > advantage of having this flexibility?
    >
    > Thanks in advance
    >
    >
    >

    If you locked the file without specifying a region, it uses
    Long.MAX_VALUE to represent the entire file. See the doc for
    FileChannel.lock() (as opposed to lock(long position,long size, boolean
    shared))
    David Zimmerman, Jul 28, 2003
    #1
    1. Advertising

  2. On Mon, 28 Jul 2003 11:00:45 -0700, "VX" <> wrote:
    > I have a question about the new FileLock functionality in java.nio packages.
    >
    > I wrote a little test code like this
    >
    >
    > FileInputStream f=new FileInputStream("xyz.txt");
    > FileChannel fc=f.getChannel();
    > System.out.println("The size of the file is: " + fc.size() );
    >
    > //now the file lock
    > FileLock lock=fc.lock(); //***this is suppose to lock the entire file
    > System.out.println("The size of the lock is: " + lock.size());
    >
    > Now here is the the problem. the size given by FileChannel is about 306
    > bytes (which is ok). ***But the size give by the lock is 9007199254740991
    > bytes!!!


    Correct. Since you did not specify a lock region size, the
    default is to give you the maximum allowable size in order
    to accomodate possible file growth, so like the API docs
    say, the actual lock size is Long.MAX_VALUE. Not sure why
    you are getting something slightly smaller (2^53-1) but that
    might be the max size of a file on your system (but that's
    just a wild assed guess). I suspect the actual lock size
    you get is adjusted to implementation specific limits.

    > I also checked the API docs...here is what it says
    > size
    > public final long size()Returns the size of the locked region in bytes.
    > A locked region need not be contained within, or even overlap, the actual
    > underlying file, so the value returned by this method may exceed the file's
    > current size.
    >
    >
    >
    > Returns:
    > The size of the locked region
    > Here are my questions:
    > 1: Does this means that my lock has locked a region of 9007199254740991
    > bytes. What will happen to any other file saved in that region?


    Nothing. This lock represents this file only. You haven't
    actually been given that a memory region that large, it's
    purely logical. Even a modern 64 bit OS would have severe
    problems getting a virtual mem block that large if it were
    even possible. Locks are implememented as ranges only,
    not as contiguous regions of memory. Or that's my
    understanding.

    > 2:What is this locked region if it doesnt 'contained within or even overlap
    > with the actual underlying file' ?


    I'm not sure but I suspect you can create a lock region that
    is currently outside the bounds of the file. For example,
    your file is 306 bytes in size, but you could do this:

    fc.lock(fc.size(),Long.MAX_VALUE,false);

    This locks the region starting at the end of the file and
    going to the largest possible size. So to begin with the
    locked region is outside the bounds of the file, but if
    the file grows, that will no longer be true.

    > 3: why should the lock size exceed the current file size. What is the
    > advantage of having this flexibility?


    So the file can grow in size and still be locked. If the
    default lock size where the size of the file, then any growth
    of the file would result in some part being outside the lock
    region and hence not protected. Locks are fixed in size so
    in order to allow growth, they chose to make the lock size,
    if unspecified, as large as possible. This is all explained
    in the docs for FileChannel.lock().

    Bear in mind I am new to these API's as well, but this is
    my current understanding. I'm sure others will set me
    straight if I've gotten it wrong ;-)

    --Joe
    Joseph Millar, Jul 28, 2003
    #2
    1. Advertising

  3. "VX" <> writes:
    > Now here is the the problem. the size given by FileChannel is about 306
    > bytes (which is ok). ***But the size give by the lock is 9007199254740991
    > bytes!!!


    I haven't looked into it in detail, but I can think of two
    possibilities:

    (1) In order to ensure that the complete file is still locked, even whe
    you grow it, the lock is aquired up to the maximum length possible on
    that operating system

    (2) You see an artefact of doing region locking on an operating system
    that only supports file locking. So as a consequence, the maximum
    possible file size is reported as locked because that is the "smallest"
    region one can get on systems that don't do region locking.

    I guess the maximum file size on your system is 9007199254740991 (which
    equals 0x1FFFFFFFFFFFFF = 2^53 - 1).

    > Here are my questions:
    > 1: Does this means that my lock has locked a region of 9007199254740991
    > bytes.


    Yes, logically! It does not mean that there are anywhere 2^53 - 1 bytes
    allocated for the lock. It means that every part of your file, until it
    reaches 2^53 - 1 is locked. If your file is smaller, only that smaller
    part is locked (you can't lock something that doesn't exist :)).

    > What will happen to any other file saved in that region?


    Nothing will happen to other files, because that region does not apply
    to them. That region is NOT any reserved space on the hard disk. It is
    the logical size the lock spawns over that one file. No other file will
    be saved in that region, because it does not exist as any kind of disk
    space.

    > 2:What is this locked region if it doesnt 'contained within or even overlap
    > with the actual underlying file' ?


    The locked region is the part of the file to which you application
    has exclusive access (for varying degrees of exclusive).

    A lock region outsite of the file simply means that the operating
    system can't grant you exclusive access to the desired part of the
    file. E.g. if the operating system does not support any kind of file
    locking, it could simply return a size of 0.

    > 3: why should the lock size exceed the current file size. What is the
    > advantage of having this flexibility?


    See (1) and (2) above. You could grow the file, and still all parts of
    the file are locked. Or it is a workaround for a missing region-lock
    feature of your OS.

    /Thomas
    Thomas Weidenfeller, Jul 28, 2003
    #3
  4. David Zimmerman

    VX Guest

    I have a question about the new FileLock functionality in java.nio packages.

    I wrote a little test code like this


    FileInputStream f=new FileInputStream("xyz.txt");
    FileChannel fc=f.getChannel();
    System.out.println("The size of the file is: " + fc.size() );

    //now the file lock
    FileLock lock=fc.lock(); //***this is suppose to lock the entire file
    System.out.println("The size of the lock is: " + lock.size());

    Now here is the the problem. the size given by FileChannel is about 306
    bytes (which is ok). ***But the size give by the lock is 9007199254740991
    bytes!!!

    I also checked the API docs...here is what it says
    size
    public final long size()Returns the size of the locked region in bytes.
    A locked region need not be contained within, or even overlap, the actual
    underlying file, so the value returned by this method may exceed the file's
    current size.



    Returns:
    The size of the locked region
    Here are my questions:
    1: Does this means that my lock has locked a region of 9007199254740991
    bytes. What will happen to any other file saved in that region?
    2:What is this locked region if it doesnt 'contained within or even overlap
    with the actual underlying file' ?
    3: why should the lock size exceed the current file size. What is the
    advantage of having this flexibility?

    Thanks in advance
    VX, Jul 28, 2003
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    0
    Views:
    5,214
  2. Replies:
    4
    Views:
    8,459
    toddwh50
    Mar 11, 2010
  3. siliconwafer

    confused abt file operations

    siliconwafer, Aug 30, 2005, in forum: C Programming
    Replies:
    8
    Views:
    331
    Gordon Burditt
    Aug 31, 2005
  4. boris

    confused abt what to choose!

    boris, May 6, 2007, in forum: Java
    Replies:
    4
    Views:
    287
    Oliver Wong
    May 9, 2007
  5. alejandrina

    Problem with FileLock

    alejandrina, Jul 13, 2007, in forum: Java
    Replies:
    12
    Views:
    631
    alejandrina
    Jul 30, 2007
Loading...

Share This Page