lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20220316190615.495163ae@suse.de>
Date:   Wed, 16 Mar 2022 19:06:15 +0100
From:   David Disseldorp <ddiss@...e.de>
To:     Vasant Karasulli <vkarasulli@...e.de>
Cc:     Namjae Jeon <linkinjeon@...nel.org>,
        Sungjong Seo <sj1557.seo@...sung.com>,
        linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
        Takashi Iwai <tiwai@...e.de>
Subject: Re: [PATCH v3 2/2] exfat: keep trailing dots in paths if
 keep_last_dots is

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ