HOWTO: Case-Preserving behaivor in Linux (BSDs? Solaris?)
Dave Maxwell <Dave_Maxwell <at> bigwalnut.k12.oh.us>
2005-10-28 13:38:48 GMT
A perennial thorn in my side using Netatalk on Linux servers over the
years is the case-sensitive behavior of the server. It seems to randomly
break saving from certain apps and totally breaks file-served educational
software like Reading Counts, SRI, and Star Reading.
For those of you new to the issue, here is what happens. The default
filesystems on BSD, UNIX, and Linux OSes are case-sensitive. File.txt,
file.txt, and FILE.TXT refer to three different files on most filesystems
available to these OSes. Mac OS (X or 9.x and earlier) and Windows on the
other hand exhibit what is called case-preserving insensitive behavior.
This means that a file in a directory can be named File.txt OR file.txt OR
FILE.txt but all three filenames can only refer to one file. If you try
create two variations in case on the same filename you will be informed in
some fashion that the file already exists. Mac OS and Windows apps are
often coded with this behavior as an implicit assumption and Bad Things
can happen when working with files on a case-sensitive server. For
instance, Reading Counts might try to write to a file called INDEX.IDX but
read it back in as index.idx. Of course, the software dies horribly.
Windows machines don't have problems when served files from a Samba server
because the server daemon itself makes sure the client sees
case-preserving behavior. You will only run into trouble if you use means
outside Samba itself to manually create files that break case-preserving
behavior, perhaps using touch at a console to create break_winders and
BREAK_WINDERS in a Samba share. Or maybe those clever Samba guys check
for that too. I never tried it. Netatalk on the other hand makes no
attempt to impose behavior on a the served filesystem apart from making
sure the client sees a compatible charset for filenames. Netatalk running
on a Windows or OS X box will not present problems for the client because
the underlying filesystem behavior of NTFS and HFS+ is case-preserving.
On a 'nix box, the filesystem being served is more than likely
case-sensitive and hilarity ensues. This can be solved with the casefold
options which force filenames to be all uppercase or all lowercase.
Indeed I created casefolded shares for my educational apps and got them
running that way. It is still unsuitable for user shares because users
expect to be able to name files to their liking.
A year ago it occurred to me that if I created a case-preserving
filesystem on a 'nix box and shared that then it might solve my problems.
I found that was indeed the case. My problem apps ran correctly served
from an HPFS filesystem mounted on loopback. That was no help. I cannot
create or integrity HPFS filesystems on any 'nix. I used a blank
filesystem image I downloaded to test this. I then went through every
other case-preserving filesystem available to me on Linux:
HFS : A glitch I never figured out. The problem apps didn't want to run
HFS+ : Deleted files never returned their space to the filesystem. You
can fill up HFS+ on Linux by repeatedly creating files then deleting them.
Even Darwin's own fsck couldn't fix this.
VFAT : This would have been hideous even if it did work. The are odd
subtleties of naming that broke things.
HPFS: Worked well but could not create or check these filesystems.
And with that, I ran out of ideas. I had a solution but couldn't
implement it. This was the state of things for a year and half after my
initial elated discovery.
I recently discovered that jfs filesystems can be created with
case-preserving behavior "for OS/2 compatibility". On Linux at least jfs
is solid. The filesystem works as well as any other. You can create and
Here is how to get case-preserving behavior with Netatalk on Linux:
Create a JFS filesystem with the "-O" option for case-preserving behavior:
# mkfs.jfs -O /dev/sda1
Mount the filesystem somewhere suitable:
# mount -t jfs /dev/sda1 /mnt/macshare
Add the filesystem to Applevolumes.default:
If other OSes have jfs or some other case-preserving filesystem available
along with the utilities to create and maintain them then the same general
solution should work. The drawback of course is the shared filesystem
will have reduced utility on OSes that expect case-sensitive behaivor.
Certain shell scripts in particular may break when run on such a volume.
It isn't a problem for my application as the shares exist exclusively to
Big Walnut Local Schools
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information