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.
