United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-4243868 : File.setLastModified(long) has GC-dependent failure (win98)

Details
Type:
Bug
Submit Date:
1999-06-04
Status:
Closed
Updated Date:
2006-12-13
Project Name:
JDK
Resolved Date:
2006-12-13
Component:
core-libs
OS:
windows_98,windows_95
Sub-Component:
java.io
CPU:
x86
Priority:
P4
Resolution:
Not an Issue
Affected Versions:
1.2.1,1.2.2
Fixed Versions:

Related Reports

Sub Tasks

Description
Name: krT82822			Date: 06/03/99


The call to java.io.File.setLastModified() will occasionally fail
on Windows98 machines using FAT32 filesystem.

This happens on plain files, not directories as suggested by
the fixes to 4177432 and 4156354.

The standard JIT shows this symptom the most.
Turning off JIT reduces the frequency of the problem.
Performing a gc() just prior to the setLastModified() call
in addition to turning off the JIT seems to make it work
almost all of the time.  This suggests a resource retention
bug.

Using HOTSPOT JIT with its GC scheme also improves but doesn't
fix the problem.

Please contact me for an example and script to evoke the problem.
(Review ID: 83748) 
======================================================================

                                    

Comments
WORK AROUND



Name: krT82822			Date: 06/03/99


Place a java.lang.System.gc() before setLastModified call.
======================================================================
                                     
2004-06-11
EVALUATION

This bug was submitted in 1999 reporting that the setLastModified method sometimes fails on Windows 98. There isn't sufficient information in the bug report to know if "fail" means that the method returns false, or that a subsequent invocation of the lastModified method returned an unexpected timestamp. 

If the issue is that the method is returning false then it means that the method failed to update the modification time. Without knowing anything about the file or the environment then it is not possible to diagnose the issue. The submitter mentions that invoking the GC or disabling the JIT helps and this suggests perhaps a timing issue - maybe slowing down the java application gives sufficient time for something else that is accessing the file to complete (which suggests perhaps the issue is a file locking problem).

If the issue is that the method is returning true then the modification time should be updated. One issue with FAT is that it has a 2-second resolution for the modification time. Some of the JDC comments mention that the time is always an even number of seconds or that modifying the modification time on a newly created file doesn't seem to work. This is a limitation of the file system. A related point is that the java.io.File spec says that the platform supports at least a resolution of 1 second - this spec issue is tracked as 4788477.

Based on the above, and the fact that we no longer support Windows 98, I am closing this bug.
                                     
2006-12-13



Hardware and Software, Engineered to Work Together