AbstractBasicFileAttributeView.java (version 1.5 : 49.0, super bit)
Mark Thornton
mthornton at optrak.co.uk
Fri Feb 27 08:01:40 PST 2009
Alan Bateman wrote:
> Helmut Schwigon wrote:
>> Hallo Allan,
>> lot of thanks for Your prompt answer!
>> I run in this problem while I tried to implement an automatic test
>> case generator for a file filter. I think this is a rare application
>> and not a real problem for the rest of the world. On the other hand I
>> can't see any important reason why dates in the past before
>> 01.01.1970 00:00:00 UTC will be handled different from dates in the
>> future even if it is needed in very rare cases only.
>>
>> Helmut
>>
> There isn't any technical reason and you are right that it is an
> inconsistency (Eamonn McManus also pointed point this inconsistency
> when reviewing the API). It requires a bit of thought and it may be
> that the only thing we can do is allow it and specify that attempting
> to set a time stamp to a value that pre-dates the file system/volume
> results in undefined behavior. It is easy to find examples of
> operating systems and file system combinations where it results in the
> file's time stamp being set to the epoch, or where it silently wraps
> around and sets it to some time in the future, or where it fails (by
> throwing an IOException). Thanks again for bringing this up.
>
> -Alan.
>
In my opinion, the least surprising behaviour would be for the time
stamp values to be clamped at the minimum/maximum values supported by
the file system.
Mark Thornton
More information about the nio-dev
mailing list