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 ...

[David Disseldorp <ddiss@suse.de>]

Hi T.Kohada,

On Mon, 14 Mar 2022 03:52:08 +0000, Kohada.Tetsuhiro@dc.MitsubishiElectric.co.jp wrote:

> Hi, Vasant Karasulli.
> 
> > > > 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.  
> 
> The exfat specification specifies an invalid character set, but there are no restrictions on the use of leading or trailing white-space or dots.
> Even if the filename has trailing-dot as shown below, it conforms to the exfat specification and can be created on Windows.
> "a"
> "a."
> "a.."
> These are treated as "a" in the current implementation of linix-exfat, so the intended file cannot be accessed.
> The specified filename should not be modified to comply with the exfat specification.
> Therefore, exfat_striptail_len() should not be used.
> 
> Note:
> Windows explorer removes trailing white-space and dots, but not the behavior of the filesystem.
> Also, you can create a trailing-dot filename by quoting it on the command line.

Please explain how you came to that conclusion.
I did some further tests using the win32 CopyFile() API directly[1] on
Windows10 and observe that both trailing periods and trailing spaces are
trimmed for an exfat destination path.

Cheers, David

1: calling win32 CopyFile() from powershell
https://devblogs.microsoft.com/scripting/use-powershell-to-interact-with-the-windows-api-part-1/