Kevin Ballard [off-list ref] writes:
On Jan 11, 2008, at 7:40 PM, Johannes Schindelin wrote:
quoted
On Fri, 11 Jan 2008, Junio C Hamano wrote:
quoted
Kevin Ballard [off-list ref] writes:
quoted
Is there a reason for this? It seems like it would be trivial to end
up with misdiagnosed "untracked" files when using any language other
than English given this behaviuor.
No. The assumption of the code has always been that sane filesystems
would return from readdir() the names you gave from creat().
We do not really have to rehash that whole discussion for the Nth
time, do
we?
Apparently so. By Junio's definition, HFS+ is not a sane filesystem,
and as git grows more popular with OS X users, this issue is going to
crop up more frequently.
It's not "my" definition, but you asked the reason and I gave
the answer. We can close this issue of "is HFS+ sane" now.
HFS+ is insane, period. And as Linus said, you cannot forgive
its insanity using the historical baggage argument, like MS-DOS.
HOWEVER.
It is a totally different issue if we want to refuse supporting
insane filesystems. And the answer is no. It was not my
intention to say that we do not intend to support them, when I
explained the reason why the things are as they are, which was
the original question by you.
See Robin's proposal to let us translate random names we get
back from readdir() from the filesystem using an additional
look-up table in the index extension section that stores mapping
from canonicalized form to the form that the user registered to
the index. I think that is a sane approach to tackle this issue
on insane filesystems like HFS+.
On Jan 11, 2008, at 8:30 PM, Junio C Hamano wrote:
quoted
Apparently so. By Junio's definition, HFS+ is not a sane filesystem,
and as git grows more popular with OS X users, this issue is going to
crop up more frequently.
It's not "my" definition, but you asked the reason and I gave
the answer. We can close this issue of "is HFS+ sane" now.
HFS+ is insane, period. And as Linus said, you cannot forgive
its insanity using the historical baggage argument, like MS-DOS.
Fair enough, though I believe OS X has a good reason, namely it's an
OS designed for regular users rather than servers or programmers. Case-
sensitivity would confuse my mother.
HOWEVER.
It is a totally different issue if we want to refuse supporting
insane filesystems. And the answer is no. It was not my
intention to say that we do not intend to support them, when I
explained the reason why the things are as they are, which was
the original question by you.
Ok. I wasn't implying anything with that phrase there, I was just
trying to reiterate that HFS+ is case-insensitive and emphasize that
this issue will become more relevant as time goes by.
See Robin's proposal to let us translate random names we get
back from readdir() from the filesystem using an additional
look-up table in the index extension section that stores mapping
from canonicalized form to the form that the user registered to
the index. I think that is a sane approach to tackle this issue
on insane filesystems like HFS+.
If I knew what the index extension section was, perhaps I would think
that's a good idea ;) I have yet to dive into the gory details of how
this stuff works.
--
Kevin Ballard
http://kevin.sb.org
kevin@sb.org
http://www.tildesoft.com
On Fri, Jan 11, 2008 at 08:43:35PM -0500, Kevin Ballard wrote:
Fair enough, though I believe OS X has a good reason, namely it's an
OS designed for regular users rather than servers or programmers. Case-
sensitivity would confuse my mother.
Many of *nix servers are running web-services and samba servers, yet most
users are even not aware of whether they dealing with case-sensitive file
system or not, let alone being confused by that. This is because most
regular users will type the name only once when they create a new file
and then just click on this name. So case-sensitive file systems can
really confuse only some badly written applications...
Dmitry