All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Disseldorp <ddiss@suse.de>
To: Vasant Karasulli <vkarasulli@suse.de>
Cc: Namjae Jeon <linkinjeon@kernel.org>,
	Sungjong Seo <sj1557.seo@samsung.com>,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	Takashi Iwai <tiwai@suse.de>
Subject: Re: [PATCH v3 2/2] exfat: keep trailing dots in paths if keep_last_dots is
Date: Wed, 16 Mar 2022 19:06:15 +0100	[thread overview]
Message-ID: <20220316190615.495163ae@suse.de> (raw)
In-Reply-To: <20220311114746.7643-3-vkarasulli@suse.de>

Hi Vasant,

A couple of things I missed in the previous round...

On Fri, 11 Mar 2022 12:47:46 +0100, Vasant Karasulli wrote:

> exfat currently unconditionally strips trailing
> periods '.' when performing path lookup, but allows them in the filenames
> during file creation.

Trailing periods *are* currently stripped during creation, so that
statement should be removed, e.g.

  The Linux kernel exfat driver currently unconditionally strips
  trailing periods '.' from path components.

> This is done intentionally, loosely following Windows
> behaviour and specifications which state:
> 
>   #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.
> On Windows 10, File Explore application retains leading and trailing
> space characters. But on the commandline behavior was exactly the opposite.

As mentioned earlier, my observations from Windows10 CopyFile() win32
API calls were that trailing spaces and periods are stripped. AFAICT
that's also the case for Windows Explorer and cmd.exe paths.

Cheers, David

      reply	other threads:[~2022-03-16 18:06 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-11 11:47 [PATCH v3 0/2] exfat: allow access to paths with trailing dots Vasant Karasulli
2022-03-11 11:47 ` [PATCH v3 1/2] exfat: add keep_last_dots mount option Vasant Karasulli
2022-03-13  0:01   ` Namjae Jeon
2022-03-16  9:20     ` Vasant Karasulli
2022-03-16 13:57       ` David Disseldorp
2022-03-16 14:08         ` Namjae Jeon
2022-03-16 14:44           ` Vasant Karasulli
2022-03-11 11:47 ` [PATCH v3 2/2] exfat: keep trailing dots in paths if keep_last_dots is Vasant Karasulli
2022-03-16 18:06   ` David Disseldorp [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=20220316190615.495163ae@suse.de \
    --to=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 \
    --cc=vkarasulli@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 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.