Re: ext3/ext2 kernel bug with umlauts?
On Wed, Oct 01, 2008 at 08:39:45AM +0200, Martin Michlmayr wrote:
> * Michael Glockenstein <debdevel2008@glockenstein.de> [2008-09-30 14:32]:
> > Because I got no answer from Theodore too, I ask me now what happens
> > when lenny is released as stable, do we have to live with this problem
> > until the next stable debian version? Or does the armel platform does
> > not follow the hard debian rules and a new kernel can be released even
> > in the live time of lenny?
>
> There will be kernel updates lenny after lenny is released and this
> bug would certainly be a good candidate for such an update. However,
> let's hope Ted comes up with a solution before lenny is released.
Just to give you an update, I found the root cause of the problem, and
am working on a fix. It's actually an old problem that I had known
about for a while, and I had designed a fix, but had only gotten
around to implementing the userspace part of the fix in e2fsprogs. I
had never gotten around to implementing the rest of it since it only
shows up if you try migrating a filesystem back and forth between
architectures where char (without any specifier) is signed --- as God
and K&R C intended --- and unholy, thrice-cursed demon-spawned
architectures arising the depths of heck where "char" is unsigned. :-)
The bug was the original hash algorithms, which Daniel Phillips
authored, and which used bare "char" pointers. This turns out not to
be portable, since on some architectures, including PowerPC and,
apparently ARM, "char" is defined to be unsigned, and if you want to
get signed chars, you have to explicitly ask for them via the "signed"
keyword. By the time we discovered this problem two years ago, it was
too late to fix without breaking existing filesystems, so the fix was
to add two flags which indicated whether the hash should be calculated
using signed or unsigned.
I designed and implemented this solution for userspace, but never got
around to implementing it on the kernel-side, since (a) it was rare
that filesystems would be created on one system and moved to another,
and (b) since I only tend to use the US-ASCII character set in
filenames, it didn't bother me, and (c) between putting in 16-18 hours
work/day for my day job, it just never rose to the top of my priority
queue, and over time, I completely forgot about the issue.
Anyway, the fix isn't that hard to implement; I'll just have to get it
coded up and then pushed upstream.
- Ted
Reply to: