From: "Sungjong Seo" <sj1557.seo@samsung.com>
To: "'Rover'" <739817562@qq.com>, "'linkinjeon'" <linkinjeon@kernel.org>
Cc: "'linux-kernel'" <linux-kernel@vger.kernel.org>,
"'linux-fsdevel'" <linux-fsdevel@vger.kernel.org>,
<sj1557.seo@samsung.com>
Subject: RE: RE: [PATCH v1] exfat: remove the code that sets FileAttributes when renaming
Date: Wed, 14 Sep 2022 19:22:43 +0900 [thread overview]
Message-ID: <08bb01d8c823$ed1e0dd0$c75a2970$@samsung.com> (raw)
In-Reply-To: <tencent_52978C540CBFA2747B715C811F0D99530E07@qq.com>
> Hi Sungjong,
>
> This patch is to remove the duplicate setting ATTR_ARCHIVE when renaming.
>
> We know that a file will not become a directory after being renamed, and a
> directory will not become a file after being renamed.
Sure, rename-op does not change any types of files.
> >>
> >> *epnew = *epold;
> So ATTR_ARCHIVE is already set here if rename file.
Do you think ATTR_ARCHIVE represents the file type? If so, you probably
are misunderstanding ATTR_ARCHIVE. It's just like a flag indicating that
there was a change. For example, in case of rename, it's just like a flag
indicating that its name has been changed.
The current linux exfat implementation does not yet provide an IOCTL
to control this attribute, but keep in mind that the ATTR_ARCHIVE may
be removed even if it is a file via another exfat driver.
B.R.
Sungjong Seo
>
> >> - if (exfat_get_entry_type(epnew) == TYPE_FILE) {
> >> - epnew->dentry.file.attr |=
> cpu_to_le16(ATTR_ARCHIVE);
> No need to set again here.
>
> >> - ei->attr |= ATTR_ARCHIVE;
> ei->attr doesn't change and already set ATTR_ARCHIVE in
> exfat_fill_inode()
>
> >> - }
>
> Best regards,
> Rover
>
> ------------------ Original ------------------
> From: "Sungjong Seo" <sj1557.seo@samsung.com>;
> Date: Wed, Sep 14, 2022 04:48 PM
> To: "Rover"<739817562@qq.com>;"'linkinjeon'"<linkinjeon@kernel.org>;
> Cc: "'linux-kernel'"<linux-kernel@vger.kernel.org>;"'linux-
> fsdevel'"<linux-
> fsdevel@vger.kernel.org>;"sj1557.seo"<sj1557.seo@samsung.com>;
> Subject: RE: [PATCH v1] exfat: remove the code that sets FileAttributes
> when renaming
>
>
> Hi, Rover,
>
> This patch seems to violate the exFAT specification below.
> Please refer to the description for ATTR_ARCHIVE in FAT32 Spec.
>
> * Archive
> This field is mandatory and conforms to the MS-DOS definition.
>
> * ATTR_ARCHIVE
> This attribute supports backup utilities. This bit is set by the FAT file
> system driver when a file is created, renamed, or written to. Backup
> utilities may use this attribute to indicate which files on the volume
> have been modified since the last time that a backup was performed.
>
> Thanks.
> B.R.
>
> Sungjong Seo
>
> > When renaming, FileAttributes remain unchanged, do not need to be
>
> set, so the code that sets FileAttributes is unneeded, remove it.
> >
> > Signed-off-by: rover &lt;739817562@qq.com&gt; > ---
> > fs/exfat/namei.c | 12 ------------ > 1 file changed,
> 12 deletions(-) > > diff --git a/fs/exfat/namei.c b/fs/exfat/namei.c
> > index b617bebc3d0f..5ffaf553155e 100644 > --- a/fs/exfat/namei.c
> > +++ b/fs/exfat/namei.c > @@ -1031,10 +1031,6 @@ static int
> exfat_rename_file(struct inode *inode, > struct exfat_chain *p_dir,
> > return -EIO; > > *epnew = *epold; > -if
> (exfat_get_entry_type(epnew) == TYPE_FILE) { > - epnew-
> &gt;dentry.file.attr |= > cpu_to_le16(ATTR_ARCHIVE); > - ei-
> &gt;attr |= ATTR_ARCHIVE; > -} > exfat_update_bh(new_bh,
> sync); > brelse(old_bh); > brelse(new_bh); > @@ -
> 1063,10 +1059,6 @@ static int exfat_rename_file(struct inode *inode, >
> struct exfat_chain *p_dir, > ei-&gt;dir = *p_dir; >
> ei-&gt;entry = newentry; > } else { > -if
> (exfat_get_entry_type(epold) == TYPE_FILE) { > - epold-
> &gt;dentry.file.attr |= > cpu_to_le16(ATTR_ARCHIVE); > - ei-
> &gt;attr |= ATTR_ARCHIVE; > -} > exfat_update_bh(old_bh,
> sync); > brelse(old_bh); > ret =
> exfat_init_ext_entry(inode, p_dir, oldentry, > @@ -1112,10 +1104,6 @@
> static int exfat_move_file(struct inode *inode, > struct exfat_chain
> *p_olddir, > return -EIO; > > *epnew = *epmov; > -
> if (exfat_get_entry_type(epnew) == TYPE_FILE) { > -epnew-
> &gt;dentry.file.attr |= cpu_to_le16(ATTR_ARCHIVE); > -ei-
> &gt;attr |= ATTR_ARCHIVE; > - } > exfat_update_bh(new_bh,
> IS_DIRSYNC(inode)); > brelse(mov_bh); > brelse(new_bh);
> > -- > 2.25.1</sj1557.seo@samsung.com></linux-
> fsdevel@vger.kernel.org></linux-
> kernel@vger.kernel.org></linkinjeon@kernel.org></sj1557.seo@samsung.com>
parent reply other threads:[~2022-09-14 10:23 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <tencent_52978C540CBFA2747B715C811F0D99530E07@qq.com>]
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='08bb01d8c823$ed1e0dd0$c75a2970$@samsung.com' \
--to=sj1557.seo@samsung.com \
--cc=739817562@qq.com \
--cc=linkinjeon@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).