On 4/18/20 8:03 AM, Namjae Jeon wrote:
> 2020-04-16 13:11 GMT+09:00, Eric Sandeen <sandeen@xxxxxxxxxxx>:
> Hi Eric,
>
>> exfat atimes are restricted to only 2s granularity so after
>> we set an atime, round it down to the nearest 2s and set the
>> sub-second component of the timestamp to 0.
> Is there any reason why only atime is truncated with 2s granularity ?
You're the expert, so I might be wrong! :)
My reading of the spec & code is that every timestamp has 2s granularity, in the
main time field, and some timestamps also have another field with 10ms granularity,
which can range from 0 to 199, i.e. 0 to 1990 ms, i.e. 0 to 1.99 seconds in the _ms
field. i.e. the _ms fields can add more than 1 second to the timestamp, right?
struct {
__u8 num_ext;
__le16 checksum;
__le16 attr;
__le16 reserved1;
__le16 create_time;
__le16 create_date;
__le16 modify_time;
__le16 modify_date;
__le16 access_time;
__le16 access_date;
__u8 create_time_ms;
__u8 modify_time_ms;
__u8 create_tz;
__u8 modify_tz;
__u8 access_tz;
__u8 reserved2[7];
} __packed file; /* file directory entry */
and per the publiished spec,
7.4.8.1 DoubleSeconds Field
The DoubleSeconds field shall describe the seconds portion of the Timestamp field, in two-second multiples.
The valid range of values for this field shall be:
0, which represents 0 seconds
29, which represents 58 seconds
7.4.9 10msIncrement Fields
10msIncrement fields shall provide additional time resolution to their corresponding Timestamp fields in ten-millisecond multiples.
The valid range of values for these fields shall be:
At least 0, which represents 0 milliseconds
At most 199, which represents 1990 milliseconds
since access_time has no corresponding 10msIncrement field, my understanding was that it could only have a 2s granularity.
Happy to have the patch dropped or corrected if I read this wrong, though.
-Eric
