Invalid argument exception when trying to seek FilePosition to LONG.MAX_VALUE

[Karan Mehta]

> It's just an alias for llseek. You should be able to see the value of the
offset specified to the syscall, it will be 9223372036854775807 when you
use fc.position(Long.MAX_VALUE).

Since the value passed to syscall is LONG.MAX_VALUE, we can confirm that it
is indeed lseek64, otherwise it would have been some negative number.

> I'm not sure what you mean by "swallowing" the exception here.
FileChannel.position(long) is implemented to use lseek64 and I think is
failing with values larger than the file system. I don't think
Integer.MAX_VALUE is an issue.

Let me clarify this a bit further. If the underlying FS throws an exception
while seeking to LONG.MAX_VALUE, the JNI call should catch it and return a
No-op to the Java function, instead of throwing it back further.

> This is with ext4, right?  XFS is fine with it and can even write there:

Can't speak for XFS, but yeah with ext4 is where I am seeing the issue.

On Wed, Jun 5, 2019 at 8:31 AM Florian Weimer <fweimer at redhat.com> wrote:

> * Alan Bateman:
>
> > On 04/06/2019 18:13, Karan Mehta wrote:
> >
> >  Hello everyone,
> >
> >  Apache bookkeeper project uses Java NIO to read journal files from
> disk. Recently a change was made that would seek the file to
> >  LONG.MAX_VALUE. When we tried running this on a test inside a docker
> container with openjdk:8-jdk image, it results in
> >  IOException. The patch fix PR is here. Furthermore, running it inside
> the same container on different hardware throws IOException
> >  either while seeking the file to LONG.MAX_VALUE or when reading the
> file at that value as per the link of the interface here.
> >  Checkout the comment here. I am suspecting this to be a JNI related
> issue or bug. Let me know what you all think and if there's
> >  any better way to figure this out.
> >
> > I just checked this on macOS and Linux. macOS seems happy with lseek'ing
> to LONG.MAX_VALUE, Linux does not:
> >
> > [pid 34168] lseek(4, 9223372036854775807, SEEK_SET) = -1 EINVAL (Invalid
> argument)
>
> This is with ext4, right?  XFS is fine with it and can even write there:
>
> info: maximum writable file offset: 9223372036854775806 (7ffffffffffffffe)
> info: writing out of range fails with Invalid argument (22)
>
> Thanks,
> Florian
>


-- 
Karan Mehta

<http://smart.salesforce.com/sig/k.mehta//us_mb/default/link.html>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20190605/2268d514/attachment.html>