You can set Samba's filename case sensitivity in /etc/samba/smb.conf. From man 5 smb.conf,

The options are:

mangle case = yes/no
        controls if names that have characters that aren't of the
        "default" case are mangled. For example, if this is yes
        then a name like "Mail" would be mangled. Default no.

case sensitive = yes/no
        controls whether filenames are case sensitive. If they
        aren't then Samba must do a filename search and match on
        passed names. Default no.

default case = upper/lower
        controls what the default case is for new filenames.
        Default lower.

preserve case = yes/no
        controls if new files are created with the case that the
        client passes, or if they are forced to be the "default"
        case. Default yes.

short preserve case = yes/no
        controls if new files which conform to 8.3 syntax, that is
        all in upper case and of suitable length, are created upper
        case, or if they are forced to be the "default" case. This
        option can be use with "preserve case = yes" to permit long
        filenames to retain their case, while short names are low
­         ercased. Default yes.

Nothing much to be done about the win32 box not caring when it looks up files, though.

Yes, it's annoying. The only defence I've heard is that it makes it 'easier' to type filenames, but everyone I know found it suprising, so I going with 'naughty, based on the principle of least suprise'. Not that anyone's going to fix it thesedays :)

I have the reverse problem. Using Fedora 2, the lack of Unicode on the Windows network leaves me unable to interact properly with a lot of files, particularly if the directory name contains a Windows ANSI character like á, which is invalid Unicode.

I often have to drop down to the CLI, use tab completion to find my way down to the file, since I can't type the directory name as Samba wants to see it, then copy it somewhere sensible so that I can open it is OOo or similar. That's just frustrating!

I suppose this comment doesn't have much to do with Perl... Um, well, at least FC2 solved its Unicode with Perl issues so I don't have to constantly change locales!

Did said developer remember to convert line endings from DOSish to Linux-ish? Or will that be next week's Meditation? ;)

My development group has been using Cygwin for almost a year and have been extremely pleased with it. You get the best of both worlds - it truly is a wonderful thing. And, most open-source distros have a Cygwin-build option. :-)

Here's the beautiful thing - modern source control systems will handle the line-ending issues. The case-sensitivity crap is something that Windows (and only Windows) users have to deal with. Mac OS-X, being a BSD-based system, doesn't have those issues.

. You get the best of both worlds - it truly is a wonderful thing. And, most open-source distros have a Cygwin-build option

Well it makes the bad world a little less painful, but anything involving Windows is not the best of any world. For the record, I vastly prefer a MinGW environment to cygwin. Faster, and actually maintained to some degree...

> Gods, why do IT/IS groups continue to insist on this stupidity?!?

> Being right, does not endow the right to be rude; politeness costs nothing.
> Being unknowing, is not the same as being stupid.

Maybe they're just "unknowing". And maybe your mantra is really just a meaningless soundbite that even you don't believe.

Me, I love the irony. Thanks for the chuckle.

Case sensitivity and system security

---

If you are installing Windows Services for UNIX on Windows XP or Windows Server 2003, you might be required to choose whether to change the default behavior of object names such as file names to being case sensitive. The choice you make will affect system security as well as how Windows Services for UNIX functions.

In Windows, the names of most objects (such as files and directories) are case preserving, but case insensitive. That means you can use uppercase and lowercase characters when naming such objects, but Windows does not distinguish between names based on case alone. For example, you cannot have two files in the same directory named sample.txt and Sample.txt because Windows regards the names to be identical for the purposes of identifying files. The UNIX operating system, on the other hand, is fully case sensitive, and so UNIX computers distinguish between object names when the only difference between those names is the case of characters used in the object names. On most UNIX computers, therefore, sample.txt and Sample.txt could appear in the same directory, and the UNIX computer would distinguish between them when performing operations on the files. For example, the command rm S*.txt would delete Sample.txt but not sample.txt.

In order to implement typical UNIX behavior, the Server for NFS and the Interix subsystem are normally case sensitive when working with file names. This can present security issues, particularly for Windows users who are accustomed to the case-insensitive conventions of Windows. For example, a Trojan horse version of edit.exe named EDIT.EXE could be stored in the same directory as edit.exe. If a user were to type edit at a Windows command prompt, the Trojan horse version (EDIT.EXE) could be executed instead of the standard version. If case sensitivity is enabled, Windows users should be made aware of this possibility.

In Windows XP and Windows Server 2003, the default behavior of subsystems other than the Win32 subsystem is to be case preserving but case insensitive; in previous versions of Windows, such subsystems were fully case sensitive by default. In order to support standard UNIX behavior, Windows Services for UNIX Setup allows you to change the default Windows XP and Windows Server 2003 behavior for non-Win32 subsystems when installing the base utilities (which installs the Interix subsystem) or Server for NFS. If you enable case sensitivity and then subsequently uninstall Server for NFS and the base utilities, Windows Services for UNIX Setup will restore the default, case-insensitive behavior of non-Win32 subsystems