FileInputStream.skip() is broken in Linux (32-bit) on large files

[chrism778]

The skip() method appears to be broken in the Java 1.5.05 JVM for
kernel 2.6.9 of Linux (32-bit) when you pass in a value larger than
Integer.MAX_VALUE. I keep getting an "IOException: Invalid Argument"
when trying to skip more than Integer.MAX_VALUE bytes in a file larger
than Integer.MAX_VALUE.

This method works fine in Windows XP (32-bit) against the exact same
large files. I also tried a newer JVM (1.5.12), but had the same
problem.

Does anyone know of a workaround or fix for this? Thanks.


- Chris

 

[chrism778]

The skip() method appears to be broken in the Java 1.5.05 JVM for
kernel 2.6.9 of Linux (32-bit) when you pass in a value larger than
Integer.MAX_VALUE. I keep getting an "IOException: Invalid Argument"
when trying to skip more than Integer.MAX_VALUE bytes in a file larger
than Integer.MAX_VALUE.

This method works fine in Windows XP (32-bit) against the exact same
large files. I also tried a newer JVM (1.5.12), but had the same
problem.

Does anyone know of a workaround or fix for this? Thanks.

- Chris

Turns out the problem was with the mount we were using to connect from
Linux to a Windows file system. We were using smbfs which only
supports 2GB files. Once we switched to cifs the problem went away.

 

[Roedy Green]

The skip() method appears to be broken in the Java 1.5.05 JVM for
kernel 2.6.9 of Linux (32-bit) when you pass in a value larger than
Integer.MAX_VALUE.

are you by any chance failing to append a trailing L to your literal?

 

[Lew]

are you by any chance failing to append a trailing L to your literal?

There would've been a compiler error, no?

From the JLS:

 

[Andrew Thompson]

The skip() method appears to be broken in the Java 1.5.05 JVM for
kernel 2.6.9 of Linux (32-bit) when you pass in a value larger than
Integer.MAX_VALUE. I keep getting an "IOException: Invalid Argument"
when trying to skip more than Integer.MAX_VALUE bytes in a file larger
than Integer.MAX_VALUE. ...
Does anyone know of a workaround or fix for this?

I note you had found a work-around for the current
installation, by changing the FS. Assuming the FS
were not open for adjustment to this apps. needs,
I was wondering if this simple little hack might work.

..
long target = Integer.MAX_VALUE*5l + 7l;
while ( target>Integer.MAX_VALUE ) {
fis.skip( Integer.MAX_VALUE );
target -= Integer.MAX_VALUE;
}
fis.skip( target );
..

A test by the OP under the original conditions would
be interesting, but I am also interested in hearing
theoretical comments.

--
Andrew Thompson
http://www.athompson.info/andrew/

Message posted via JavaKB.com
http://www.javakb.com/Uwe/Forums.aspx/java-general/200709/1

 

[chrism778]

I note you had found a work-around for the current
installation, by changing the FS. Assuming the FS
were not open for adjustment to this apps. needs,
I was wondering if this simple little hack might work.

.
long target = Integer.MAX_VALUE*5l + 7l;
while ( target>Integer.MAX_VALUE ) {
fis.skip( Integer.MAX_VALUE );
target -= Integer.MAX_VALUE;
}
fis.skip( target );
.

A test by the OP under the original conditions would
be interesting, but I am also interested in hearing
theoretical comments.

Andrew,

I had already tried that and it didn't work. The second you exceed
2GB (even if it doesn't happen until your second call to skip()) you
get the same error.

 

[chrism778]

are you by any chance failing to append a trailing L to your literal?

Nope. Eclipse wouldn't allow that anyway.

P.S. You have a very helpful website (mindprod.com)! I've been a
visitor for years.

 

[Roedy Green]

There would've been a compiler error, no?

It may be fixed now, but there was a time when long literals without
the L were quietly truncated on the high end.

 

[Esmond Pitt]

It may be fixed now, but there was a time when long literals without
the L were quietly truncated on the high end.

It was fixed in about 1998.

 

[Lew]

It was fixed in about 1998.

Nevertheless, Rudy's right that one should use the L for long literals. This
is especially true for values near (long) INT_MAX or (long) INT_MIN. But why
try to remember when you must use 'L' and when it's optional, or force code
maintainers to? Just use it whenever you intend a long literal.

 

[Lew]

It was fixed in about 1998.

Nevertheless, Roedy's right that one should use the L for long literals. This
is especially true for values near (long) INT_MAX or (long) INT_MIN. But why
try to remember when you must use 'L' and when it's optional, or force code
maintainers to? Just use it whenever you intend a long literal.

 

[Esmond Pitt]

Nevertheless, ... one should use the L for long literals.

as the compiler has been forcing you to do since 1998.

 

[Andrew Thompson]

Nevertheless, Rudy's ..

<grin>
Eye Haight spell chequers.
</grin>

--
Andrew Thompson
http://www.athompson.info/andrew/

Message posted via JavaKB.com
http://www.javakb.com/Uwe/Forums.aspx/java-general/200709/1

 

[Lew]

<grin>
Eye Haight spell chequers.
</grin>

Yes, I am really, really, really sorry about that.

 

[Roedy Green]

Nevertheless, Roedy's right that one should use the L for long literals. This
is especially true for values near (long) INT_MAX or (long) INT_MIN.

The problem I get nailed on every once is a while is comparing
Integer.MAX_VALUE. As soon as you start doing arithmetic or
comparisons in values in that range, cast to longs, on use
MAX_VALUE/2 if all you wanted was "a very large value, larger than any
that would occur in "nature""