JDK-6652379 : File.setLastModified fails on large files (lnx only)
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.io
  • Affected Version: 6,6u24
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: linux
  • CPU: x86
  • Submitted: 2008-01-18
  • Updated: 2011-05-18
  • Resolved: 2011-05-18
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 7
7 b30Fixed
Related Reports
Duplicate :  
Description
FULL PRODUCT VERSION :
java version "1.6.0_03"
Java(TM) SE Runtime Environment (build 1.6.0_03-b05)
Java HotSpot(TM) Client VM (build 1.6.0_03-b05, mixed mode, sharing)

ADDITIONAL OS VERSION INFORMATION :
Linux files1 2.6.23-gentoo-r3 #1 Sat Dec 8 22:17:26 CET 2007 i686 AMD Athlon(tm) XP 3200+ AuthenticAMD GNU/Linu

EXTRA RELEVANT SYSTEM CONFIGURATION :
Glibc version is 2.6.1, file system is ext3


A DESCRIPTION OF THE PROBLEM :
setLastModified() and setReadOnly() and probably other methods fail to work on large files.  The large file (~3.5GB) was sucessfully written with java.io.OutputStream.write(byte[] b, int off, int len) and should be finally modified by setLastModified() and setReadOnly(), which fail.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
File system with small and large files:
output of ls -l:
insgesamt 3752980
-rw-r--r-- 1 ralf users       1000 23. Dez 14:45 change.class
-rw-r--r-- 1 ralf users 3839287296 31. Okt 23:30 large
-rw-r--r-- 1 ralf users          6  1. Jan 1970  small

Call supplied source code: java change Filename



EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
I expect the code to work on the large file as it works on the small file.

output of  "java change small" is:
Absolute path: /mnt/files1/lib/Filme/2/small
File exists: true
Set modification time: true

ACTUAL -
output of "java change large" is:
Absolute path: /mnt/files1/lib/Filme/2/large
File exists: true
Set modification time: false



ERROR MESSAGES/STACK TRACES THAT OCCUR :
output of "strace -vf java change small" is:
...
[pid 15158] write(1, "File exists: true", 17) = 17
[pid 15158] write(1, "\n", 1)           = 1
[pid 15158] stat64("small", {st_dev=makedev(254, 0), st_ino=15089665, st_mode=S_
IFREG|0644, st_nlink=1, st_uid=1000, st_gid=100, st_blksize=4096, st_blocks=8, s
t_size=6, st_atime=2007/12/23-14:40:50, st_mtime=0, st_ctime=2007/12/23-15:18:36
}) = 0
[pid 15158] utimes("small", {{1198417250, 0}, {0, 0}}) = 0
[pid 15158] write(1, "Set modification time: true", 27) = 27
...

output of "strace -vf java change large" is:
...
[pid 15137] write(1, "File exists: true", 17) = 17
[pid 15137] write(1, "\n", 1)           = 1
[pid 15137] stat64("large", {st_dev=makedev(254, 0), st_ino=16826370, st_mode=S_
IFREG|0644, st_nlink=1, st_uid=1000, st_gid=100, st_blksize=4096, st_blocks=7505
944, st_size=3839287296, st_atime=2007/11/16-03:18:24, st_mtime=2007/10/31-23:30
:52, st_ctime=2007/12/23-15:05:37}) = 0
[pid 15137] utimes("large", {{3084935236, 134574080}, {0, 0}}) = -1 EINVAL (Inva
lid argument)
[pid 15137] write(1, "Set modification time: false", 28) = 28
...


REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
change.java is:

import java.io.File;
public class change {
	public static void main(String[] args) {
		File file = new File(args[0]);
		System.out.println("Absolute path: " + file.getAbsolutePath());
		System.out.println("File exists: " + file.exists());
		System.out.println("Set modification time: " + file.setLastModified(0L));
	}
}
---------- END SOURCE ----------

Comments
EVALUATION setLastModified is incorrectly using stat instead of stat64 on Linux. This problem is only visible now because of changes in the 2.6.22 kernel whereby utimes returns EINVAL for cases where it didn't in the past. This is easy to fix and probably should be fixed in 5.0 and 6.0 updates too.
18-01-2008