RE: [PATCH] exfat: use local UTC offset when EXFAT_TZ_VALID isn't set

[Sungjong Seo]

> 2021-10-05 13:05 GMT+09:00, Sungjong Seo <sj1557.seo@xxxxxxxxxxx>:
> >> 2021-10-01 22:19 GMT+09:00, Sungjong Seo <sj1557.seo@xxxxxxxxxxx>:
> >> > Hello, Namjae,
> >> Hi Sungjong,
> >> >
> >> > I found an important difference between the code we first wrote and
> >> > the code that has changed since our initial patch review. This
> >> > difference seems to cause compatibility issues when reading saved
> >> timestamps without timezone.
> >> > (In our initial patch review, there were concerns about possible
> >> > compatibility issues.) I think the code that reads timestamps
> >> > without timezone should go back to the concept we wrote in the
> >> > first place like reported patch.
> >> Are you talking about using sys_tz?
> > Yes, exactly, a part like below.
> Have you read discussion about this before ?

Of course. That's why I wrote the expression "go back".
As you know, there was the discussion of local time conversion method for
reading timestamps that have no OffsetValid bit.
that is, whether to use sys_tz or not was the main topic.

And I understand that the current exFAT implementation doesn't use sys_tz
and depends entirely on time_offset.(UTC if time_offset is not set)

> Let me know what I am missing something.

No, there is nothing you are missing.
I thought compatibility issues regarding sys_tz could be serious
because I misunderstood that other compatibility issues were reported. :(

I am just concerned that most system daemons mount exfat-fs without
time_offset option, which could be reported as a compatibility issue.

However, to discuss this more, it would be nice to see the trend of how
many issues regarding sys_tz will be reported.

> 
> >
> > +static inline int exfat_tz_offset(struct exfat_sb_info *sbi) {
> > +	return (sbi->options.tz_set ? -sbi->options.time_offset :
> > +			sys_tz.tz_minuteswest) * SECS_PER_MIN; }
> > +
> >
> >>
> >> > It could be an answer of another timestamp issue.
> >> What is another timestamp issue ?
> >
> > What I'm saying is "timestamp incompatibilities in exfat-fs" from
> > Reiner <reinerstallknecht@xxxxxxxxx> I think it might be the same
> > issue with this.
> Have you checked fuse-exfat patch he shared ? It was exfat timezone
> support.
> I am not sure how it is related to sys_tz...

As I mentioned above, I misunderstood. :)
I mistakenly thought that the code that handles timestamp without
OffsetValid bit was added as well.

Thanks!

> 
> Thanks!
> >
> >>
> >> >
> >> > Could you please let me know what you think?
> >> >
> >> > Thanks.
> >> >> -----Original Message-----
> >> >> From: Namjae Jeon [mailto:linkinjeon@xxxxxxxxxx]
> >> >> Sent: Friday, September 10, 2021 10:01 AM
> >> >> To: Chung-Chiang Cheng <cccheng@xxxxxxxxxxxx>
> >> >> Cc: sj1557.seo@xxxxxxxxxxx; linux-fsdevel@xxxxxxxxxxxxxxx; linux-
> >> >> kernel@xxxxxxxxxxxxxxx; shepjeng@xxxxxxxxx
> >> >> Subject: Re: [PATCH] exfat: use local UTC offset when
> >> >> EXFAT_TZ_VALID isn't set
> >> >>
> >> >> 2021-09-09 15:55 GMT+09:00, Chung-Chiang Cheng
> <cccheng@xxxxxxxxxxxx>:
> >> >> > EXFAT_TZ_VALID is corresponding to OffsetValid field in exfat
> >> >> > specification [1]. If this bit isn't set, timestamps should be
> >> >> > treated as having the same UTC offset as the current local time.
> >> >> >
> >> >> > This patch uses the existing mount option 'time_offset' as fat
> does.
> >> >> > If time_offset isn't set, local UTC offset in sys_tz will be
> >> >> > used as the default value.
> >> >> >
> >> >> > Link: [1]
> >> >> > https://protect2.fireeye.com/v1/url?k=cba4edf5-943fd4c8-cba566ba
> >> >> > -0c
> >> >> > c47
> >> >> > a31309a-e70aa065be678729&q=1&e=225feff2-841f-404c-9a2e-c12064b23
> >> >> > 2d0
> >> >> > &u=
> >> >> > https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fwindows%2Fwin32%2Ffil
> >> >> > eio %2F exfat-specification%2374102-offsetvalid-field
> >> >> > Signed-off-by: Chung-Chiang Cheng <cccheng@xxxxxxxxxxxx>
> >> >> Please read this discussion:
> >> >>
> >> >> https://protect2.fireeye.com/v1/url?k=9bbcab7c-c4279381-9bbd2033-0
> >> >> 00babff317b-88ee581b44536876&q=1&e=b0d8a44b-4821-44a8-860a-4d3116c
> >> >> b634d&u=https%3A%2F%2Fpatchwork.kernel.org%2Fproject%2Flinux-
> >> >> fsdevel/patch/20200115082447.19520-10-namjae.jeon@xxxxxxxxxxx/
> >> >>
> >> >> Thanks!
> >> >
> >> >
> >
> >