RFE: provide an efficient way to retrieve Unix ctime (changed-time)

[Marc Strapetz]

On 12.10.2017 16:45, Marc Strapetz wrote:
> On 12.10.2017 15:25, Alan Bateman wrote:
>> On 12/10/2017 13:38, Marc Strapetz wrote:
>>> During a Files.walkFileTree(), UnixFileAttributes seem to be 
>>> populated with all available file system information, especially 
>>> st_ctime_sec and st_ctime_nsec, but currently there is no way to 
>>> access this information (except of using reflection-based hacks).
>>>
>>> As suggested in a comment by Alan Bateman on stackoverflow.com[1], 
>>> this information could be made available directly through 
>>> PosixFileAttributes.
>>>
>> Right, there's no type safe way to get this through the standard API 
>> although it can be obtained by attribute name using 
>> Files.getAttribute(file, "unix:ctime").
> 
> Thanks for pointing me to this method. I've tried this now

Our code is now running since several months using 
Files.getAttribute(file, "unix:ctime"), but in addition it's also using 
reflection to directly access UnixFileAttributes.ctime for a sanity 
check. Very seldom, but still, received values are different. To rule 
out file system ctime changes exactly between the invocations of both 
methods, I'm running the entire code in a loop for 10 times. Still, 
received values remain different (the assertion only applies after 
running the code 10 times, hence I can't say whether the loop breaks 
with equal values in many other cases). Differences which we have seen 
are for example (Files.getAttribute vs. reflection):

1524102538000 vs. 1524102531000
1524018734000 vs. 1524018328000
1524035923000 vs. 1524035580000
1523988895096 vs. 1523988895008
1523928063000 vs. 1523928058000

Any ideas what might cause this difference? Given the loop, I don't 
think that the observed differences are caused by frequent file system 
ctime changes.

-Marc