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.