JDK-4697792 : (spec) File.setLastModified(long) makes assumption on precision that isn't feasible everywhere
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.io
  • Affected Version: 1.4.0
  • Priority: P4
  • Status: Resolved
  • Resolution: Cannot Reproduce
  • OS: windows_2000
  • CPU: x86
  • Submitted: 2002-06-05
  • Updated: 2017-05-19
  • Resolved: 2017-05-19
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.
Other
tbd_majorResolved
Related Reports
Relates :  
Relates :  
Description
Name: nt126004			Date: 06/05/2002


FULL PRODUCT VERSION :
java version "1.4.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-b92)
Java HotSpot(TM) Client VM (build 1.4.0-b92, mixed mode)

FULL OPERATING SYSTEM VERSION :
Microsoft Windows 2000 [Version 5.00.2195]

A DESCRIPTION OF THE PROBLEM :
On some computers (all running the same JDK and same version
of Windows), File.setLastModified sets the time to the
specified time rounded up to the nearest even second.

Also on these computers setting times below a certain number
doesn't work either (method returns false).

The spec says All platforms support file-modification times
to the nearest second, but some provide more precision.  The
argument will be truncated to fit the supported precision.

Upto 2 seconds up is not to the nearest second.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. Find a particular machine that has this problem (has been
seen on some Windows 2000 and Windows 98 machines, but other
Windows 2000 machines have allowed times correct to the
millisecond)
2. create a test file (c:/temp/test.txt)
3. run the code


EXPECTED VERSUS ACTUAL BEHAVIOR :
Expected: both tests to succeed and for the times displayed
to be within half a second of the last modified times displayed.

Actual: 1st test is out by almost 2 seconds, 2nd test
returns false

This bug can be reproduced always.

---------- BEGIN SOURCE ----------
import java.io.*;

public class Test {
  public static void main(String[] args) {
    File f = new File("c:/temp/test.txt");
    System.out.println("Last Modified Time: " + f.lastModified());
    System.out.println("Setting Time to 1023199010001 succeeded: " +
f.setLastModified(1023199010001L));
    System.out.println("Last Modified Time: " + f.lastModified());
    System.out.println("Setting Time to 1000 succeeded: " +
f.setLastModified(1000));
    System.out.println("Last Modified Time: " + f.lastModified());
  }
}
---------- END SOURCE ----------

CUSTOMER WORKAROUND :
when comparing modified times allow for up to 4 seconds in
differences and hope that no computers are further away from
spec
(Review ID: 148188) 
======================================================================

Comments
Unable to produce on any of the usual platforms.
2017-05-19

Running the provided code on Windows 7 in the manner directed but with the file "test.txt" in the same folder as the Test class, I do not see the described behavior for JDK8b111, nor the current builds of JDK9-internal nor JDK10-internal. I am inclined to think that it is likely not an issue but could have been fixed in some other patch since almost 15 years ago.
2017-05-18

The Windows GetFileTime() documentation states: "Not all file systems can record creation and last access times and not all file systems record them in the same manner. For example, on FAT, create time has a resolution of 10 milliseconds, write time has a resolution of 2 seconds, and access time has a resolution of 1 day (really, the access date). Therefore, the GetFileTime function may not return the same file time information set using the SetFileTime function."
2017-05-18