| Message ID | 1591663760-6418-1-git-send-email-Hyeongseok@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | exfat: clear filename field before setting initial name | expand |
Hi Hyeongseok, > Some fsck tool complain that padding part of the FileName Field is not set to the value 0000h. So > let's follow the filesystem spec. > > Signed-off-by: Hyeongseok.Kim <Hyeongseok@gmail.com> > --- > fs/exfat/dir.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/fs/exfat/dir.c b/fs/exfat/dir.c index de43534..6c9810b 100644 > --- a/fs/exfat/dir.c > +++ b/fs/exfat/dir.c > @@ -424,6 +424,9 @@ static void exfat_init_name_entry(struct exfat_dentry *ep, > exfat_set_entry_type(ep, TYPE_EXTEND); > ep->dentry.name.flags = 0x0; > > + memset(ep->dentry.name.unicode_0_14, 0, > + sizeof(ep->dentry.name.unicode_0_14)); > + > for (i = 0; i < EXFAT_FILE_NAME_LEN; i++) { > ep->dentry.name.unicode_0_14[i] = cpu_to_le16(*uniname); > if (*uniname == 0x0) Wouldn't it be better to fill the rest with 0x0000 in this loop? > -- > 2.7.4
> Some fsck tool complain that padding part of the FileName Field is not set > to the value 0000h. So let's follow the filesystem spec. As I know, it's specified as not "shall" but "should". That is, it is not a mandatory for compatibility. Have you checked it on Windows? > > Signed-off-by: Hyeongseok.Kim <Hyeongseok@gmail.com> > --- > fs/exfat/dir.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/fs/exfat/dir.c b/fs/exfat/dir.c index de43534..6c9810b 100644 > --- a/fs/exfat/dir.c > +++ b/fs/exfat/dir.c > @@ -424,6 +424,9 @@ static void exfat_init_name_entry(struct exfat_dentry > *ep, > exfat_set_entry_type(ep, TYPE_EXTEND); > ep->dentry.name.flags = 0x0; > > + memset(ep->dentry.name.unicode_0_14, 0, > + sizeof(ep->dentry.name.unicode_0_14)); > + > for (i = 0; i < EXFAT_FILE_NAME_LEN; i++) { > ep->dentry.name.unicode_0_14[i] = cpu_to_le16(*uniname); > if (*uniname == 0x0) > -- > 2.7.4
On 6/9/20 12:03 PM, Sungjong Seo wrote: >> Some fsck tool complain that padding part of the FileName Field is not set >> to the value 0000h. So let's follow the filesystem spec. > As I know, it's specified as not "shall" but "should". > That is, it is not a mandatory for compatibility. > Have you checked it on Windows? Right, it's not mandatory and only some fsck'er do complain for this. But, there's no benefit by leaving the garbage bytes in the filename entry. Isn't it? Or, are you saying about the commit message? >> Signed-off-by: Hyeongseok.Kim <Hyeongseok@gmail.com> >> --- >> fs/exfat/dir.c | 3 +++ >> 1 file changed, 3 insertions(+) >> >> diff --git a/fs/exfat/dir.c b/fs/exfat/dir.c index de43534..6c9810b 100644 >> --- a/fs/exfat/dir.c >> +++ b/fs/exfat/dir.c >> @@ -424,6 +424,9 @@ static void exfat_init_name_entry(struct exfat_dentry >> *ep, >> exfat_set_entry_type(ep, TYPE_EXTEND); >> ep->dentry.name.flags = 0x0; >> >> + memset(ep->dentry.name.unicode_0_14, 0, >> + sizeof(ep->dentry.name.unicode_0_14)); >> + >> for (i = 0; i < EXFAT_FILE_NAME_LEN; i++) { >> ep->dentry.name.unicode_0_14[i] = cpu_to_le16(*uniname); >> if (*uniname == 0x0) >> -- >> 2.7.4 > >
On 6/9/20 11:36 AM, Namjae Jeon wrote: > Hi Hyeongseok, > >> Some fsck tool complain that padding part of the FileName Field is not set to the value 0000h. So >> let's follow the filesystem spec. >> >> Signed-off-by: Hyeongseok.Kim <Hyeongseok@gmail.com> >> --- >> fs/exfat/dir.c | 3 +++ >> 1 file changed, 3 insertions(+) >> >> diff --git a/fs/exfat/dir.c b/fs/exfat/dir.c index de43534..6c9810b 100644 >> --- a/fs/exfat/dir.c >> +++ b/fs/exfat/dir.c >> @@ -424,6 +424,9 @@ static void exfat_init_name_entry(struct exfat_dentry *ep, >> exfat_set_entry_type(ep, TYPE_EXTEND); >> ep->dentry.name.flags = 0x0; >> >> + memset(ep->dentry.name.unicode_0_14, 0, >> + sizeof(ep->dentry.name.unicode_0_14)); >> + >> for (i = 0; i < EXFAT_FILE_NAME_LEN; i++) { >> ep->dentry.name.unicode_0_14[i] = cpu_to_le16(*uniname); >> if (*uniname == 0x0) > Wouldn't it be better to fill the rest with 0x0000 in this loop? OK, I'll change like that. >> -- >> 2.7.4 > > . >
> On 6/9/20 12:03 PM, Sungjong Seo wrote: > >> Some fsck tool complain that padding part of the FileName Field is > >> not set to the value 0000h. So let's follow the filesystem spec. > > As I know, it's specified as not "shall" but "should". > > That is, it is not a mandatory for compatibility. > > Have you checked it on Windows? > Right, it's not mandatory and only some fsck'er do complain for this. > But, there's no benefit by leaving the garbage bytes in the filename entry. > Isn't it? > Or, are you saying about the commit message? The latter, I'm just saying this is not a spec-violation :) > >> Signed-off-by: Hyeongseok.Kim <Hyeongseok@gmail.com> > >> --- > >> fs/exfat/dir.c | 3 +++ > >> 1 file changed, 3 insertions(+) > >> > >> diff --git a/fs/exfat/dir.c b/fs/exfat/dir.c index de43534..6c9810b > >> 100644 > >> --- a/fs/exfat/dir.c > >> +++ b/fs/exfat/dir.c > >> @@ -424,6 +424,9 @@ static void exfat_init_name_entry(struct > >> exfat_dentry *ep, > >> exfat_set_entry_type(ep, TYPE_EXTEND); > >> ep->dentry.name.flags = 0x0; > >> > >> + memset(ep->dentry.name.unicode_0_14, 0, > >> + sizeof(ep->dentry.name.unicode_0_14)); > >> + > >> for (i = 0; i < EXFAT_FILE_NAME_LEN; i++) { > >> ep->dentry.name.unicode_0_14[i] = cpu_to_le16(*uniname); > >> if (*uniname == 0x0) > >> -- > >> 2.7.4 > > > >
On 6/9/20 1:55 PM, Sungjong Seo wrote: >> On 6/9/20 12:03 PM, Sungjong Seo wrote: >>>> Some fsck tool complain that padding part of the FileName Field is >>>> not set to the value 0000h. So let's follow the filesystem spec. >>> As I know, it's specified as not "shall" but "should". >>> That is, it is not a mandatory for compatibility. >>> Have you checked it on Windows? >> Right, it's not mandatory and only some fsck'er do complain for this. >> But, there's no benefit by leaving the garbage bytes in the filename entry. >> Isn't it? >> Or, are you saying about the commit message? > The latter, I'm just saying this is not a spec-violation :) Yes, I got it. Thanks. >>>> Signed-off-by: Hyeongseok.Kim <Hyeongseok@gmail.com> >>>> --- >>>> fs/exfat/dir.c | 3 +++ >>>> 1 file changed, 3 insertions(+) >>>> >>>> diff --git a/fs/exfat/dir.c b/fs/exfat/dir.c index de43534..6c9810b >>>> 100644 >>>> --- a/fs/exfat/dir.c >>>> +++ b/fs/exfat/dir.c >>>> @@ -424,6 +424,9 @@ static void exfat_init_name_entry(struct >>>> exfat_dentry *ep, >>>> exfat_set_entry_type(ep, TYPE_EXTEND); >>>> ep->dentry.name.flags = 0x0; >>>> >>>> + memset(ep->dentry.name.unicode_0_14, 0, >>>> + sizeof(ep->dentry.name.unicode_0_14)); >>>> + >>>> for (i = 0; i < EXFAT_FILE_NAME_LEN; i++) { >>>> ep->dentry.name.unicode_0_14[i] = cpu_to_le16(*uniname); >>>> if (*uniname == 0x0) >>>> -- >>>> 2.7.4 >>> > >
diff --git a/fs/exfat/dir.c b/fs/exfat/dir.c index de43534..6c9810b 100644 --- a/fs/exfat/dir.c +++ b/fs/exfat/dir.c @@ -424,6 +424,9 @@ static void exfat_init_name_entry(struct exfat_dentry *ep, exfat_set_entry_type(ep, TYPE_EXTEND); ep->dentry.name.flags = 0x0; + memset(ep->dentry.name.unicode_0_14, 0, + sizeof(ep->dentry.name.unicode_0_14)); + for (i = 0; i < EXFAT_FILE_NAME_LEN; i++) { ep->dentry.name.unicode_0_14[i] = cpu_to_le16(*uniname); if (*uniname == 0x0)
Some fsck tool complain that padding part of the FileName Field is not set to the value 0000h. So let's follow the filesystem spec. Signed-off-by: Hyeongseok.Kim <Hyeongseok@gmail.com> --- fs/exfat/dir.c | 3 +++ 1 file changed, 3 insertions(+)