Re: .DS_Store
- From: John Chambers <jcsd@xxxxxxxxxxxxx>
- Date: Wed, 13 Sep 2006 14:18:07 -0400
groopie wrote:
Although you write well, I did not understand your problem.
When I synch to a PC, these DS_Store files show up and do nothing. So
what? Is it an optical/aesthetic problem?
Or just write a script exepting these files from being synched. Problem
solved.
What else you don't like about the Mac? Would you show us your
"evidence?"
groopie
Well, there are a lot of little things, but there are two biggies that are
somewhat related. They are both effects of the fact that OSX's default
file system implements interpretations of characters in file names.
The best-known problem is probably the "caseless" filename matching.
We learned about this fairly quickly, when we tried loading packages
into our server that used capitalization in an English (or German)
manner, as we might distinguish "apple" and "Apple" in a dictionary.
The result was a disaster, of course. I personally rewrote one package
for which the naming convention could be easily changed. But it was
a *lot* of work which I don't want to do again. Its naming convention
is now awkward and kludgy as a result. It's easier to just say "This
won't work on OSX without a major reprogramming job."
Now, I'm sure I'm going to get some replies flaming me for what an
idiot I am for using case significantly. I won't argue. You might be
right. But as someone running a bunch of servers, I consider this
irrelevant. Some people use case significantly, and it's not my job
to tell them they're wrong. It's my job to make things work on the
servers. So I just note that OSX can't handle this, and recommend
a server that can.
(And yes, I'm familiar with OSX's unix-like file system. That comes
with vague, fuzzy warnings that some OSX apps might not work well
with it. Until those warnings are fleshed out with explicit lists of
what apps won't work, it doesn't help. If I have to port over all the
libraries because I can't trust the Mac's, I might just as well punt and
start with a system that doesn't have such problems.)
The other problem is with 8-bit chars. I've got a few things on other
unix/linux systems that use either Latin1 (ISO 8859-1) or UTF-8 file
names. When copying them to OSX with rsync or tar, I found that some
of these names are garbled. It seems that OSX doesn't just copy the bytes
unexamined; it tries to do some sort of translation. This doesn't work.
The files not only have gibberish for names; we couldn't even find code
that could open (or unlink) some of them. Copying them back to the
unix/linux boxes preserved the gibberish names, and we could open
them there, but the code doesn't work on OSX. Copying these files back
to OSX often produced different gibberish than the first time, producing
two files with gibberish names that can't be opened.
I've been doing a bunch of "i18n" work, and this sort of thing is a
good reason to not use a system. Especially when a scan of OSX fora
like this one turn up a bunch of related question, which all too often
get only feel-good non-answers, plus the occasional flame about how
it's a stupid idea. Again, we just mark it down as an OSX problem
that's a showstopper for those apps, no matter how well it might
work for others. (It's a Microsoft problem, too, of course, but we
don't consider them for servers from the start. ;-)
The common problem here is simple: The original unix filesystems
did something very useful: The only character codes that the kernel
"understands" are 0x00 (NUL) and 0x2F ('/'). The rest are "just
characters" that aren't examined or used by anything in the kernel.
This was done intentionally. It doesn't remove any capability; it
just shoves the code out of the kernel into run-time libraries. If done
in the kernel, then an app that needs it done differently is out of luck.
If done in runtime libraries, then mistakes or wrong policies can be
fixed at the application level, by simply (;-) rewriting the library to
do it differently.
In particular, tests have shown that most unix (and linux) kernels
support both Latin1 and UTF-8 names without any fuss. The kernel
doesn't do anything with chars above 0x2F; it only copies them and
tests them for equality in open() calls. So a file system with mixed
filename encoding works, in the sense that the kernel doesn't damage
any file names and leaves the hard work for apps.
I even once worked on a project where we had unix directories full of
EBCDIC file names. As long as we avoided 0x00 and 0x2F (BEL) chars,
it worked fine. The usual unix apps displayed the names sorta funny,
but that didn't hurt anything, and the silly IBM apps were happy. It
was a crufty hack, of course, and I don't recommend it. But it worked,
where "worked" was based on the fact that the unix kernel didn't know
or care about the values of chars in file names and didn't screw up any
file names. We could (and did) write our own libraries that understood
the non-ASCII encoding.
Now, I'm not really criticising OSX here. Apple is free to do what it
wants with its kernel. If it wants to block apps from doing things that
folks at Apple don't like, well fine. I just note that these things don't
work, and we'll have to use some other system for our servers if we
have apps that want to do those things. Apple has chosen to put some
features into the low-level file system that other unix systems push
out to runtime libraries. This apparently excludes some of our apps
that need to do those things differently. So we look for systems that
allow our apps to work correctly without a kernel rewrite.
(I've read a few discussions of the idea of making UTF-8 the standard
filename encoding for linux. The best answer to this is still that it's
wrong because a kernel shouldn't be decreeing *any* standard for
filename characters. It's bad enough that we can't use 0x2F; we don't
need the problems caused by a kernel enforcing interpretations on
other char codes. I can test strings for UTF-8ness myself; I don't need
or want the kernel to do it for me, because that kills packages that
use non-UTF-8 encodings. Such as EBCDIC. ;-)
Sorry if any of this offends any Mac fanatics.
And the silly spelling checker didn't like my use of the word "8ness" above. ;-)
.
- Follow-Ups:
- Re: .DS_Store
- From: Dave Balderstone
- Re: .DS_Store
- References:
- .DS_Store
- From: John Chambers
- Re: .DS_Store
- From: Jochem Huhmann
- Re: .DS_Store
- From: John Chambers
- Re: .DS_Store
- From: groopie
- .DS_Store
- Prev by Date: Re: .DS_Store
- Next by Date: Blocking Ads
- Previous by thread: Re: .DS_Store
- Next by thread: Re: .DS_Store
- Index(es):
Relevant Pages
|
