2020-04-19 1:04 GMT+09:00, Eric Sandeen <sandeen@xxxxxxxxxxx>:
> 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?
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.
Right.
>
> Happy to have the patch dropped or corrected if I read this wrong, though.
Thanks for your detail explanation:)
I just wanted to update the patch's descirption and function's
comments to make it easier for others to understand this patch and
code.
>
> -Eric
>
