All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Sungjong Seo" <sj1557.seo@samsung.com>
To: "'Namjae Jeon'" <linkinjeon@kernel.org>
Cc: "'Chung-Chiang Cheng'" <cccheng@synology.com>,
	<linux-fsdevel@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	<shepjeng@gmail.com>, <sj1557.seo@samsung.com>
Subject: RE: [PATCH] exfat: use local UTC offset when EXFAT_TZ_VALID isn't set
Date: Tue, 5 Oct 2021 23:53:58 +0900	[thread overview]
Message-ID: <d43501d7b9f8$d3f33b80$7bd9b280$@samsung.com> (raw)
In-Reply-To: <CAKYAXd_vFjVcHJxn5xau5hFNHBXc2K7o1wFHbkhz9TcCteG2Rw@mail.gmail.com>

> 2021-10-05 13:05 GMT+09:00, Sungjong Seo <sj1557.seo@samsung.com>:
> >> 2021-10-01 22:19 GMT+09:00, Sungjong Seo <sj1557.seo@samsung.com>:
> >> > 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@gmail.com> 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@kernel.org]
> >> >> Sent: Friday, September 10, 2021 10:01 AM
> >> >> To: Chung-Chiang Cheng <cccheng@synology.com>
> >> >> Cc: sj1557.seo@samsung.com; linux-fsdevel@vger.kernel.org; linux-
> >> >> kernel@vger.kernel.org; shepjeng@gmail.com
> >> >> 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@synology.com>:
> >> >> > 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@synology.com>
> >> >> 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@samsung.com/
> >> >>
> >> >> Thanks!
> >> >
> >> >
> >
> >


      reply	other threads:[~2021-10-05 14:54 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-09  6:55 [PATCH] exfat: use local UTC offset when EXFAT_TZ_VALID isn't set Chung-Chiang Cheng
2021-09-10  1:00 ` Namjae Jeon
2021-10-01 13:19   ` Sungjong Seo
2021-10-01 14:40     ` Namjae Jeon
2021-10-05  4:05       ` Sungjong Seo
2021-10-05  4:30         ` Namjae Jeon
2021-10-05 14:53           ` Sungjong Seo [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='d43501d7b9f8$d3f33b80$7bd9b280$@samsung.com' \
    --to=sj1557.seo@samsung.com \
    --cc=cccheng@synology.com \
    --cc=linkinjeon@kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=shepjeng@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.