Re: [PATCH] fs/ntfs3: Fix logic in ntfs_cmp_names_cpu

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 6/10/21 15:37, Konstantin Komarov wrote:
> So it's expected for `ls WINDOWS` to fail.

I'm confused. If this deliberate, why does cmp_fnames pass the upcase pointer
to ntfs_cmp_names_cpu? Or for that matter, why do you bother loading the
upcase block at all?

> The same behavior you can see in
> CreateFileA function with FILE_FLAG_POSIX_SEMANTICS [1]
> or in NtSetInformationFile function with FileCaseSensitiveInformation [2].

Two different things. AIUI, FILE_FLAG_POSIX_SEMANTICS passes the
SL_CASE_SENSITIVE flag through to the FS driver's IRP_MJ_CREATE function, doing
a case-sensitive lookup on what would otherwise be a normal directory. The
FileCaseSensitiveInformation flag is set on the inode and forces Windows 10 to
always do case-sensitive lookups for that directory (i.e. it's the inverse of
ext4's casefolding flag).

This issue came to my attention because I've been doing a lot of research into
NTFS recently, and want to add FileCaseSensitiveInformation support to your
driver. But obviously this issue is a blocker for that.

> We must always compare filenames with bothcase == true.

You *really* need to rename this variable, it makes no sense at it is. As I
said, as far as I can make out it means "assume that one of the strings is
already uppercase".

> There will be patch to fix this situation.

Not to be funny, but I've already provided you with one... You'll drive away
potential contributors if you ignore their patches without a good reason.




[Index of Archives]     [Linux Driver Backports]     [DMA Engine]     [Linux GPIO]     [Linux SPI]     [Video for Linux]     [Linux USB Devel]     [Linux Coverity]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux