[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-nio-dev
Subject:    AbstractBasicFileAttributeView.java (version 1.5 : 49.0, super bit)
From:       Alan.Bateman () Sun ! COM (Alan Bateman)
Date:       2009-02-27 17:45:38
Message-ID: 49A826C2.20208 () sun ! com
[Download RAW message or body]

Mark Thornton wrote:
> Alan Bateman wrote:
>> 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.
I agree that this approach, or failing if the value is out of range, 
would be less surprising but I'm concerned that this may not be 
implementable in all cases. That is, the setTimes method is intended to 
map to a utimes or equivalent so there is a dependency on the operating 
system. The system call or equivalent may complete silently or it may 
fail. Failure at least gives an opportunity to retry with an adjusted 
value if the valid range can be determined but this may not be feasible 
either (esp. with remote file systems). It's an awkward issue.

-Alan.


[prev in list] [next in list] [prev in thread] [next in thread]