Bug in File.getLastModified()

[Seán Coffey]

Ricardo,

I see that JDK-8177809[1] has been logged. The newer NIO APIs can report 
back with higher time precision and it's probably best to use those. 
JDK-6939260 is related to your issue also.

Returning a ms value not equal to the ms value used in the 
setLastModified call does seem strange.

regards,
Sean.

[1] https://bugs.openjdk.java.net/browse/JDK-8177809

On 30/03/2017 02:15, David Holmes wrote:
> Hi Ricardo,
>
> This isn't a build issue. Redirecting to core-libs-dev. Please don't 
> reply to build-dev.
>
> Thanks,
> David
>
> On 30/03/2017 12:40 AM, Ricardo Almeida wrote:
>> Hi,
>>
>> I could not raise a bug in https://bugs.openjdk.java.net/ so I hope it
>> is ok to say it here, hoping someone can take a look at it...
>>
>> File.getLastModified() always returns with second precision, losing
>> the miliseconds (i.e. a number ending in 000). I tried using
>> Files.getLastModifiedTime and it seems to work correctly as the output
>> of the following test app shows:
>>
>> Test f.lastModified [1490606336000]: false
>> Test Files.getLastModifiedTime [1490606336718]: true
>>
>> The code:
>>
>> package com.espatial.test;
>>
>> import java.io.File;
>> import java.io.IOException;
>> import java.nio.file.Files;
>>
>> public class FileTest {
>>     private static final long LM = 1490606336718L;
>>
>>     public static void main(String[] args) throws IOException {
>>         File f = new File("test.txt");
>>         f.createNewFile();
>>
>>         f.setLastModified(LM);
>>
>>         System.out.printf("Test f.lastModified [%s]: %b\n",
>> f.lastModified(), f.lastModified() == LM);
>>         System.out.printf("Test Files.getLastModifiedTime [%s]: %b\n",
>> Files.getLastModifiedTime(f.toPath()).toMillis(),
>> (Files.getLastModifiedTime(f.toPath()).toMillis() == LM));
>>
>>         f.delete();
>>     }
>> }
>>
>> Thanks you,
>> Regards,
>> Ricardo Almeida
>>