Name: akC57697 Date: 08/11/98



   The spec for java.io.File.lastModified() is unclear about
   the platform specific measurement of the time of the last modification.
   
Tha doc says:
"
    public long lastModified()
        Returns the time that the file denoted by this abstract pathname was
        last modified.
       
        @return A long value representing the time the file was
                 last modified, measured in milliseconds since the epoch
                 (00:00:00 GMT, January 1, 1970), or <code>0L</code> if the
                 file does not exist or if an I/O error occurs
       
        @throws SecurityException
                 If a security manager exists and its
                 java.lang.SecurityManager#checkRead(java.io.FileDescriptor)
                 method denies read access to the file
"

  But Windows 95/98 uses technique what stamps time for a file each 2 seconds
and withing this delay the last modification time has not been changed;
It would be helpful if this was reflected in the spec for File.lastModified():

"
-----Begin Included Message -----

Date: Mon, 10 Aug 1998 07:45:00 -0700
 From: mickf@ireland
Subject: JCK Test Failure
To: mickf@ireland
Cc: martlist@Eng, keith.brophy@ireland, ###@###.###,
        ###@###.###, ###@###.###

Hi,

Having recently begun succesful JCK testing of the JDK 1.1.6 (without J=
IT) on
Windows 95/98, I have discovered a test that fails all JDKs consistentl=
y on the
Windows 95/98 platform, but which passes on NT.

The test method is in javasoft.sqe.tests.api.java.io.File.lastModifiedT=
ests and
is called File2032(). The test fails due to the timestamping nature of =
the FAT
system on Windows 95/98 which works every 2 seconds. File2032() creates=
 and
modifies a file, then does a sleep(2000), then modifies it again. On Wi=
ndows
95/98, the lastModified() method returns the same long after each of th=
e two
modifications which consequently causes the test to fail. Our developer=
, Sue
Paice has concluded that for the test to pass consistently, the sleep t=
ime
would need to be raised to 4 seconds.

This is a 95/98 anomoly and the only solution seems to either exclude o=
r modify
the test...

I hope that this is useful,

Ben.

Ben Corrie
IT Specialist - Java Technology Centre - IBM Hursley
email: ###@###.### / phone: 01962 815713
=


---- End Included Message ----
"



======================================================================