Invalid argument exception when trying to seek FilePosition to LONG.MAX_VALUE
Karan Mehta
k.mehta at salesforce.com
Wed Jun 5 17:06:42 UTC 2019
> 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>
More information about the nio-dev
mailing list