Bug 7133 - case sensitive = no does not work with a Linux client
Summary: case sensitive = no does not work with a Linux client
Status: REOPENED
Alias: None
Product: Samba 3.2
Classification: Unclassified
Component: File services (show other bugs)
Version: 3.2.5
Hardware: Other Linux
: P3 normal
Target Milestone: ---
Assignee: Volker Lendecke
QA Contact: Samba QA Contact
URL: http://bugzilla.kernel.org/show_bug.c...
Keywords:
Depends on:
Blocks:
 
Reported: 2010-02-14 10:03 UTC by Kurt Roeckx
Modified: 2010-03-24 14:10 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Kurt Roeckx 2010-02-14 10:03:09 UTC
Hi,

I'm having problems with the case sensitivity setting when the client is using the Linux kernel cifs module, but not when using smbclient.

The problems seems to be with the NT Create AndX function that Linux uses, while smbclient uses Open AndX.

Please see the url for more information.


Kurt
Comment 1 Björn Jacke 2010-02-14 17:47:48 UTC
can you please post (here) how to reproduce the problem that you see?

My first guess is that you use the "case sensitive = yes" setting where you shouldn't.
Comment 2 Kurt Roeckx 2010-02-14 18:13:46 UTC
On the samba side you have a share with "case sensitive = no", on the Linux side you mount using the cifs filesystem  using the "nocase" option for mount.  So on both sides you set it to be case insensitive.

Opening a file with the wrong case will fail.

Please see the other bug report, it has plenty of information about what works and what doesn't and how to reproduce it.  If something is not clear ask what you need to know.
Comment 3 Björn Jacke 2010-02-15 03:34:10 UTC
the mount option is about protocol behaviour, the samba setting is about assumtions that samba should do about the underlying filesystem. So unless you have JFS created with -O you break your setup when you just set "case sensitive=no".
Comment 4 shirishpargaonkar@gmail.com 2010-02-15 05:24:44 UTC
smbclient and (smbfs, as per bug 7051) are able to access files
case insensitively against the very same Samba setup when
cifs vfs fails.
Comment 5 Björn Jacke 2010-02-15 05:57:37 UTC
bug 7051 is about an ancient samba 3.0.9 release, the reporter should update to a newer version. Again: simply setting case sensitive = no is almost always a broken setup, as described in comment #3.

Please reopen this bug if you see a problem with case sensitive = no on a (unicode aware!) case insensitive filesystem.
Comment 6 shirishpargaonkar@gmail.com 2010-02-15 06:19:15 UTC
One more thing that baffles me, with unix extensions disabled on 
cifs client (i.e. not negotiated with the Samba server), case insensitivity 
works with the same exact Samba server (settings).
Comment 7 Kurt Roeckx 2010-02-15 12:48:18 UTC
(In reply to comment #3)
> the mount option is about protocol behaviour, the samba setting is about
> assumtions that samba should do about the underlying filesystem. So unless you
> have JFS created with -O you break your setup when you just set "case
> sensitive=no".
> 

What you're describing does not seem match the documentation nor the behavior I see.  I have tried setting it to no, yes and auto and none of them allows me to access files in a case insensitive way using cifs.  That is, if the file on the server is called "File" and is stored on an ext3 filesystem, I want to be able to open it as "file".  This works with windows clients and smbclient, but not when using Linux's cifs.

All the files have an ASCII name.  I'm not sure what you mean when you talk about a "unicode aware filesystem".  Linux does not have an API to work with filenames in unicode, and a filesystem like ext3 also doesn't store the filenames in any unicode encoding.  There are various filesystems that do store the filenames in unicode, like cifs, so you have a mount option for the conversion.  Just like you have an option in smb.conf where you can select the charset.  In any case this is not that problem, I wouldn't be able to access the files at all if this was a problem.

Comment 8 Björn Jacke 2010-02-17 06:14:22 UTC
sorry, ignore my comments here please, I was indeed confused about the logic of the parameter.
Comment 9 Kurt Roeckx 2010-03-24 14:10:03 UTC
Can someone please comment on this?