Bug 15217 - Change in behavior in lookup in case insensitive mode
Summary: Change in behavior in lookup in case insensitive mode
Alias: None
Product: Samba 4.1 and newer
Classification: Unclassified
Component: File services (show other bugs)
Version: 4.14.7
Hardware: All All
: P5 major (vote)
Target Milestone: ---
Assignee: Jeremy Allison
QA Contact: Samba QA Contact
Depends on:
Reported: 2022-10-28 15:56 UTC by Rakesh Roshan
Modified: 2022-10-28 16:25 UTC (History)
0 users

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Rakesh Roshan 2022-10-28 15:56:59 UTC
I would like to report a bug in the Samba while adding an entry in the [stat_cache_add](https://gitlab.com/samba-team/samba/-/blob/master/source3/smbd/statcache.c#L74-91) method, the idea of this conditional block
        * If we are in case insentive mode, we don't need to
        * store names that need no translation - else, it
        * would be a waste.
        if (!case_sensitive && (strcmp(full_orig_name, translated_path) == 0)) {
Is if the name of the file on filesystem and the requested path are same, then no need to cache in case-insensitive mode. This [commit](https://github.com/samba-team/samba/commit/6e364c545384c5da4a0f0f0536c40394aa2e2a97)
 Prefixed the translated name with TWRP token while the original requested filename is not prefixed with the TWRP token. So, the condition is failing after the commit even if the requested filename and the filename on the filesystem match. I think either it should done before adding the TWRP token or, add the TWRP token in the original filename before making the comparison.

With this change in beahvior this is the impact. 

There are two files on the fielsystem:

1. foo.txt with contents foo
2. FOO.txt with contents FOO

In Samba 4.11, 

1. Get-Content S:\foo.txt  returns "foo"
2. Get-Content S:\FOO.txt returns "FOO"

In Samba 4.14,

1. Get-Content S:\foo.txt  returns "foo"
2. Get-Content S:\FOO.txt returns "foo"
Comment 1 Jeremy Allison 2022-10-28 16:25:52 UTC
I'm not sure this is a bug, and certainly not tested for. Having two files:


on a filesystem that is supposed to present to clients as case-insensitive is the very definition of undefined behavior. There's no way a Windows SMB2 client could ever create such a situation, you have to invoke NFS or local filesystem access to do this. Both out of scope for SMB2.

It's kind of luck-of-the-draw as to which file will be selected when "foo.txt" or any case combination th├ereof (Foo.txt, fOo.txt, fOO.txt etc.) is submitted by the client.

The fact is "kind-of" worked one way, and now another is exactly what you'd expect in such an undefined situation.

What could this possibly break on a Windows client ? It certainly would behave differently against a Windows or NetApp or other proprietary server.

Can you explain why it's essential for you to preserve the old behavior please ?