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