Java Solaris Communities Sun Store Join SDN My Profile Why Join?
 
Bug Database
Bug Detail
Quick Lists
Top 25 Bugs
Top 25 RFE's
Recently Closed Bugs
Printable Page Printable Page


Bug Database
Bug ID: 4430625
Votes 9
Synopsis Large files broken on Linux (both java.io and java.nio)
Category java:classes_io
Reported Against 1.3
Release Fixed
State 11-Closed, Not Reproducible, bug
Priority: 4-Low
Related Bugs
Submit Date 27-MAR-2001
Description




java version "1.3.0"
Java(TM) 2 Runtime Enviroment, Standard Edition (build 1.3.0)
Java HotSpot(TM) Client VM (build 1.3.0, mixed mode)

// This was run on linux kernel 2.4.
// *************

import java.io.*;

class OpenFile
{

	public static void main ( String[] args )
	{
		try
		{
				RandomAccessFile inFile = new RandomAccessFile ( args[0], "r" );
		} // end of try block

		catch ( Exception excpt )
		{
			System.out.println ( excpt.getMessage() );
			System.out.println ("There was an error in the program.");
		} // end of catch block

	} // end of main method

} // end of class

/*

Here is the error that we are recieving

***filename*** (Value too large for defined data type)
There was an error in the program.

The file this was tested on is of size 5gig. It worked on files up to 1.5gig.
*/
(Review ID: 119580) 
======================================================================
Work Around
N/A
Evaluation
Also reproducible with Linux 2.2, which silently truncates large offsets to
zero instead of throwing an IOException.  NIO has the same problem.

--   xxxxx@xxxxx   2001/10/3

Causes errors on 2.2 kernel but using a 2.4 machine I didn't encounter any errors.

  xxxxx@xxxxx   2002-04-11
I checked jdk5 and jdk6 on both 2.4 and 2.6 kernels and this problem no longer exists.
Posted Date : 2009-02-26 19:25:33.0
Comments
  
  Include a link with my name & email   

Submitted On 25-NOV-2003
mokpk
I traced this problem working on Linux 2.4.22 to the 
FileChannelImp.c source file, which implements the native call 
to the "sendfile()" function. I have filed a separate bug, but 
came upon this one recently. Here is the fix:

The current code looks as follows:

#ifdef __linux__
#include <sys/sendfile.h>
#endif

JNIEXPORT jlong JNICALL
Java_sun_nio_ch_FileChannelImpl_transferTo0(JNIEnv *env,
jobject this, jint srcFD, jlong position, jlong count,  jint dstFD)
{
#ifdef __linux__
    off_t offset = (off_t)position;
    jlong n = sendfile(dstFD, srcFD, &offset, (size_t)count);

The bug is in the cast of the position to off_t, which is 
defined as a long in types.h in the linux kernel. The long in 
linux is 32bits wide only. What is needed is a long long. 

The correct code should look as follows:

#ifdef __linux__
#define __USE_FILE_OFFSET64
#include <sys/sendfile.h>
#endif

  __off64_t offset = (__off64_t)position;
  jlong n = sendfile(destFd, srcFd, &offset, (size_t)count);

The #define __USE_FILE_OFFSET64 will ensure that the 64 
bit version of sendfile() is compiled in. 

This fixes the problem. I have tested the fix and found it to 
be working well. 



PLEASE NOTE: JDK6 is formerly known as Project Mustang