Bug 9250 - Claim that Windows does not uniformly support case sensitive filesystems is bogus in some cases
Claim that Windows does not uniformly support case sensitive filesystems is b...
Status: NEW
Product: Samba 3.6
Classification: Unclassified
Component: File services
unspecified
All All
: P5 normal
: ---
Assigned To: Volker Lendecke
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-10-07 09:42 UTC by Garrett Cooper
Modified: 2012-10-07 10:35 UTC (History)
0 users

See Also:


Attachments
Step creating a multicase directories with the same case-insensitive name (31.48 KB, image/png)
2012-10-07 09:42 UTC, Garrett Cooper
no flags Details
Screenshot illustrating that Explorer recognizes mixed case paths with the same case-insensitive name (67.39 KB, image/png)
2012-10-07 09:43 UTC, Garrett Cooper
no flags Details
Samba masking the contents of /store/amazon\ MP3/ with the contents of /store/Amazon\ MP3/ (74.10 KB, image/png)
2012-10-07 09:47 UTC, Garrett Cooper
no flags Details
Move /store/amazon\ MP3 to /store/amazon\ MP3.2 and magically the contents of /store/amazon\ MP3.2 appear! (81.66 KB, image/png)
2012-10-07 09:50 UTC, Garrett Cooper
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Garrett Cooper 2012-10-07 09:42:02 UTC
Created attachment 7998 [details]
Step creating a multicase directories with the same case-insensitive name

NTFS (and thus Explorer) supports case sensitive filesystem pathing semantics [1], so the statement in smb.conf that claims the following...

       case sensitive = yes/no/auto

           ...

           case sensitive semantics). No Windows or DOS system supports
                                      ^^^^^^^^^^        ^^^^^^^^^^^^^^^
           case-sensitive filename so setting this option to auto is that same
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
           as setting it to no for them. Default auto.
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^

... is bogus on some versions of Windows (I know for certain it's bogus on Windows 7/Windows 2008 R2). The problem is that once upon a time (and on some supported Windows versions still, e.g. XP) the Win32 filesystem APIs were/are busted; I suspect that that's no longer an issue with non-Win32 apps on Windows x64 edition, but CIFS 1.x also does support case sensitivity depending upon the underlying filesystem (see FILE_CASE_SENSITIVE_SEARCH in [2]; FILE_CASE_SENSITIVE_SEARCH and FILE_CASE_PRESERVED_NAMES in [3]).

Some CIFS implementations claim to explicitly only support case-preservation (see NetApp's documentation), whereas Solaris supports mixed-case support, depending on the filesystem mode [2]. Isilon's release versions of OneFS don't appear to support mixed mode/case sensitivity [out-of-the-box] with the Likewise SMB `engine`, but they permit directory merging (`a` exists and `A` is being created/moved -- do you want to merge the views of the 2 directories?). Samba 3.6.7 does something unintuitive to Windows users and only presents the contents of whichever case wins in the path sorting algorithm employed if two or more paths exist with the same case insensitive contents, e.g. if I have `a` and `A`, samba 3.7.3 will only show me the contents of `A` and not `a`. Unfortunately this isn't helpful and is confusing when admins are dealing with mixed case client environments (Unix + Windows).

My smb.conf is as follows:

$ testparm 2>/dev/null < /dev/null
[global]
        server string = BAYONETTA
        max log size = 50
        socket options = SO_RCVBUF=64240 SO_SNDBUF=64240 TCP_NODELAY IPTOS_LOWDELAY IPTOS_THROUGHPUT
        load printers = No
        preferred master = Yes
        idmap config * : backend = tdb
        inherit acls = Yes
        aio read size = 65536
        aio write size = 65536
        map acl inherit = Yes
        directory name cache size = 0
        write cache size = 65536
        case sensitive = Yes

[scratch]
        path = /scratch
        read only = No
        veto files = /.snap/.windows/.zfs/
        vfs objects = zfsacl, shadow_copy2

[store]
        path = /store
        read only = No
        veto files = /.snap/.windows/.zfs/
        vfs objects = zfsacl, shadow_copy2
$ testparm --version
Version 3.6.7

I've attached screenshots will better illustrate what's going on with Samba.

Procedure:

1. Set `case sensitive = Yes` in the global configuration for smb.conf to force Samba to differentiate mixed-case paths.
2. Reload your samba configuration in smbd/nmbd.
3. On a unix host, cd to the share under inspection, and run `mkdir Foo foo; touch Foo/bar1 foo/bar2`.
4. Go back to Windows and note that there will be 2 separate paths available in Explorer: Foo and foo.
5. Go into each of the directories and you'll note that one set of contents is available, either bar1 or bar2 -- in my case it was equivalent to "bar1", I assume because strcmp("Foo", "foo") < 0.

References:

1. http://support.microsoft.com/kb/100625
2. http://msdn.microsoft.com/en-us/library/cc246322%28prot.20%29.aspx
3. http://msdn.microsoft.com/en-us/library/cc246323%28prot.20%29.aspx
3. http://docs.oracle.com/cd/E19082-01/820-2429/smbenvironmentoverview/index.html
Comment 1 Garrett Cooper 2012-10-07 09:43:48 UTC
Created attachment 7999 [details]
Screenshot illustrating that Explorer recognizes mixed case paths with the same case-insensitive name
Comment 2 Garrett Cooper 2012-10-07 09:47:53 UTC
Created attachment 8000 [details]
Samba masking the contents of /store/amazon\ MP3/ with the contents of /store/Amazon\ MP3/
Comment 3 Garrett Cooper 2012-10-07 09:50:19 UTC
Created attachment 8001 [details]
Move /store/amazon\ MP3 to /store/amazon\ MP3.2 and magically the contents of /store/amazon\ MP3.2 appear!
Comment 4 Garrett Cooper 2012-10-07 10:35:35 UTC
More info...

- OSX Lion (10.7.4) gets the Darwin (sic) award for silently merging directory contents when renaming in the Finder, but not making the contents of said merged directory known unless you poke at it the right way under the Finder (no screenshots here, but I did see the merged contents once in the Finder); I have the output from ssh instead:

$ uname -a
Darwin fuji-wireless.local 11.4.0 Darwin Kernel Version 11.4.0: Mon Apr  9 19:32:15 PDT 2012; root:xnu-1699.26.8~1/RELEASE_X86_64 x86_64

CIFS:

$ ls /Volumes/store-1/*mazon\ MP3
/Volumes/store-1/Amazon MP3:
bar     logs

/Volumes/store-1/amazon MP3:
bar     logs

NFS:

$ ls /Volumes/store/*mazon\ MP3
/Volumes/store/Amazon MP3:
foo     logs

/Volumes/store/amazon MP3:
bar     logs

Part of this might be the way the CIFS client is written in OSX, but I don't know enough to say whether or not this is the case.

- Fedora 17 supports mixed casing as I would expect and per the documentation...

# uname -a
Linux fallout-fedora.local 3.4.6-2.fc17.i686 #1 SMP Thu Jul 19 22:15:33 UTC 2012 i686 i686 i386 GNU/Linux
# smbclient -U gcooper '\\bayonetta\store'
Enter gcooper's password:
Domain=[WORKGROUP] OS=[Unix] Server=[Samba 3.6.7]
smb: \> ls "Amazon MP3\*"
  .                                   D        0  Sun Oct  7 01:49:11 2012
  ..                                  D        0  Sun Oct  7 01:50:41 2012
  foo                                          0  Sun Oct  7 02:23:17 2012
  logs                                D        0  Sun Oct  7 01:09:23 2012

                58335 blocks of size 33553920. 14062 blocks available
smb: \> ls "amazon MP3\*"
  .                                   D        0  Sun Oct  7 01:49:15 2012
  ..                                  D        0  Sun Oct  7 01:50:41 2012
  bar                                          0  Sun Oct  7 02:23:18 2012
  logs                                D        0  Sun Oct  7 03:07:19 2012

                58335 blocks of size 33553920. 14062 blocks available
# mount.cifs -o user=gcooper '\\bayonetta\store' /mnt/
Password for gcooper@\bayonetta\store: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
# cd /mnt/
# ls *mazon\ MP3
amazon MP3:
bar  logs

Amazon MP3:
foo  logs

And so does FreeBSD with its ancient SMB implementation...

$ sudo mount_smbfs -U gcooper '//bayonetta/store' /mnt2/
$ ls *mazon\ MP3
Amazon MP3:
foo     logs

amazon MP3:
bar     logs

So my guess is that only Unix samba-derivative clients truly support mixed case today (which I guess would match the documentation); other clients are broken for various other reasons and I wonder why (haven't looked at protocol dumps yet via Wireshark). I wonder if Tiger/Leopard suffers from this (whichever version was the last version to use samba.org's SMB implementation), but this is good enough proof for now that something's rotten according to the spec as noted above and the samba.org CIFS implementation -_-.

So funny how inconsistent the results are.