linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Vasant Karasulli <vkarasulli@suse.de>
To: Namjae Jeon <linkinjeon@kernel.org>
Cc: David Disseldorp <ddiss@suse.de>,
	Sungjong Seo <sj1557.seo@samsung.com>,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	Takashi Iwai <tiwai@suse.de>
Subject: Re: [PATCH v2 2/2] exfat currently unconditionally strips trailing periods '.' when performing path lookup, but allows them in the filenames during file creation. This is done intentionally, loosely following Windows behaviour and specifications which state:
Date: Fri, 11 Mar 2022 10:22:32 +0100	[thread overview]
Message-ID: <YisU2FA7EBeguwN5@vasant-suse> (raw)
In-Reply-To: <CAKYAXd_ij3WqJHQZvH458XRwLBtboiJnr-fK0hVPDi_j_8XDZQ@mail.gmail.com>

On Fr 11-03-22 18:03:57, Namjae Jeon wrote:
> 2022-03-11 5:06 GMT+09:00, David Disseldorp <ddiss@suse.de>:
> > Thanks for reworking these changes, Vasant.
> >
> > Please trim the 1/2 and 2/2 patch subjects down to around 50 chars
> > (including a "exfat: " prefix), with the details moved into the commit
> > message body...
> >
> > On Thu, 10 Mar 2022 15:24:55 +0100, Vasant Karasulli wrote:
> >
> >>   #exFAT
> >>   The concatenated file name has the same set of illegal characters as
> >>   other FAT-based file systems (see Table 31).
> >>
> >>   #FAT
> >>   ...
> >>   Leading and trailing spaces in a long name are ignored.
> >>   Leading and embedded periods are allowed in a name and are stored in
> >>   the long name. Trailing periods are ignored.
> >>
> >> Note: Leading and trailing space ' ' characters are currently retained
> >> by Linux kernel exfat, in conflict with the above specification.
> >
> > I think it makes sense to mention your findings from the Windows tests
> > here. E.g. "Windows 10 also retains leading and trailing space
> > characters".
> Windows 10 do also strip them. So you can make another patch to strip
> it as well as trailing periods.
Actually I found contradicting behavior between Window 10 File Explorer and
Commandline. Commandline seems to strip trailing spaces, but File Explorer
doesn't.

> >
> >> Some implementations, such as fuse-exfat, don't perform path trailer
> >> removal. When mounting images which contain trailing-dot paths, these
> >> paths are unreachable, e.g.:
> >>
> >>   + mount.exfat-fuse /dev/zram0 /mnt/test/
> >>   FUSE exfat 1.3.0
> >>   + cd /mnt/test/
> >>   + touch fuse_created_dots... '  fuse_created_spaces  '
> >>   + ls -l
> >>   total 0
> >>   -rwxrwxrwx 1 root 0 0 Aug 18 09:45 '  fuse_created_spaces  '
> >>   -rwxrwxrwx 1 root 0 0 Aug 18 09:45  fuse_created_dots...
> >>   + cd /
> >>   + umount /mnt/test/
> >>   + mount -t exfat /dev/zram0 /mnt/test
> >>   + cd /mnt/test
> >>   + ls -l
> >>   ls: cannot access 'fuse_created_dots...': No such file or directory
> >>   total 0
> >>   -rwxr-xr-x 1 root 0 0 Aug 18 09:45 '  fuse_created_spaces  '
> >>   -????????? ? ?    ? ?            ?  fuse_created_dots...
> >>   + touch kexfat_created_dots... '  kexfat_created_spaces  '
> >>   + ls -l
> >>   ls: cannot access 'fuse_created_dots...': No such file or directory
> >>   total 0
> >>   -rwxr-xr-x 1 root 0 0 Aug 18 09:45 '  fuse_created_spaces  '
> >>   -rwxr-xr-x 1 root 0 0 Aug 18 09:45 '  kexfat_created_spaces  '
> >>   -????????? ? ?    ? ?            ?  fuse_created_dots...
> >>   -rwxr-xr-x 1 root 0 0 Aug 18 09:45  kexfat_created_dots
> >>   + cd /
> >>   + umount /mnt/test/
> >>
> >> With this change, the "keep_last_dots" mount option can be used to access
> >> paths with trailing periods and disallow creating files with names with
> >> trailing periods. E.g. continuing from the previous example:
> >>
> >>   + mount -t exfat -o keep_last_dots /dev/zram0 /mnt/test
> >>   + cd /mnt/test
> >>   + ls -l
> >>   total 0
> >>   -rwxr-xr-x 1 root 0 0 Aug 18 10:32 '  fuse_created_spaces  '
> >>   -rwxr-xr-x 1 root 0 0 Aug 18 10:32 '  kexfat_created_spaces  '
> >>   -rwxr-xr-x 1 root 0 0 Aug 18 10:32  fuse_created_dots...
> >>   -rwxr-xr-x 1 root 0 0 Aug 18 10:32  kexfat_created_dots
> >
> > It'd be nice to demonstrate "keep_last_dots" creation here as well, e.g.
> >
> >   + echo > kexfat_created_dots_again...
> >   sh: kexfat_created_dots_again...: Invalid argument
> >
> > @Namjae: not sure whether this is what you had in mind for preventing
> > creation of invalid paths. What's your preference?
> Look like what I wanted.
That's great. I will resend the patch after modifying the commit message
as David suggested.
>
> Thanks!
> >
> > Cheers, David
> >

Thanks,
Vasant Karasulli
Kernel generalist
www.suse.com<http://www.suse.com>
[https://www.suse.com/assets/img/social-platforms-suse-logo.png]<http://www.suse.com/>
SUSE - Open Source Solutions for Enterprise Servers & Cloud<http://www.suse.com/>
Modernize your infrastructure with SUSE Linux Enterprise servers, cloud technology for IaaS, and SUSE's software-defined storage.
www.suse.com


  reply	other threads:[~2022-03-11  9:22 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-10 14:24 [PATCH v2 0/2] exfat: allow access to paths with trailing dots Vasant Karasulli
2022-03-10 14:24 ` [PATCH v2 1/2] The "keep_last_dots" mount option will, in a subsequent commit, control whether or not trailing periods '.' are stripped from path components during file lookup or file creation Vasant Karasulli
2022-03-10 14:24 ` [PATCH v2 2/2] exfat currently unconditionally strips trailing periods '.' when performing path lookup, but allows them in the filenames during file creation. This is done intentionally, loosely following Windows behaviour and specifications which state: Vasant Karasulli
2022-03-10 20:06   ` David Disseldorp
2022-03-11  9:03     ` Namjae Jeon
2022-03-11  9:22       ` Vasant Karasulli [this message]
2022-03-14  3:52         ` [PATCH v2 2/2] exfat currently unconditionally strips trailing periods '.' when performing path lookup, but allows them in the filenames during file creation. This is done intentionally, loosely following Windows behaviour and specifications which Kohada.Tetsuhiro
2022-03-16 13:45           ` David Disseldorp
2022-03-17  9:15             ` Kohada.Tetsuhiro

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=YisU2FA7EBeguwN5@vasant-suse \
    --to=vkarasulli@suse.de \
    --cc=ddiss@suse.de \
    --cc=linkinjeon@kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sj1557.seo@samsung.com \
    --cc=tiwai@suse.de \
    /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).