confused abt FileLock behavior

[David Zimmerman]

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))

 

[Joseph Millar]

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

 

[Thomas Weidenfeller]

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

 

[VX]

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