I have seen such filesystems in the wild. Imagine that a virtual filesystem has to make up metadata for an object not actually stored, e.g. a directory for a file system backed by a source code control system that does not have directory artifacts. Filesystem authors are likely to pick the value 0 for timestamps, even though that is likely to cause trouble (later than 2000 is much safer).
On Mon, May 22, 2017 at 1:22 PM, Brian Burkhalter < brian.burkhal...@oracle.com> wrote: > https://bugs.openjdk.java.net/browse/JDK-8180767 > http://cr.openjdk.java.net/~bpb/8180767/webrev.00/ > > java.io.File#lastModified() returns zero if the file in question does not > exist. If however the file does exist and by some fantastic improbability > has a last-modified time equal to the epoch, then a caller literally > following the specification verbiage would interpret the returned value of > zero as signifying that the file does not exist. It would probably be ideal > to throw a FileNotFoundException when the file does not exist, but instead > here we propose to return unity (1) instead of zero when the last-modified > time of the file equals the epoch. > > Note that this webrev is with respect to the one for [1] which is > currently pending CCC approval, and is shown in the webrev in the JDK 9 > tree. As it contains code changes, it would however be pushed to JDK 10 > after the patch for [1] has been pushed and eventually migrated into the > JDK 10 repository. > > Thanks, > > Brian > > [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2017- > May/047787.html
