Michael Weissenbacher wrote:
>i've investigated this problem further the last days and came to the
>following conclusions:
>[...]
>fsck does not like all contain german umlauts. but otoh there are
>filenames with umlauts that are ok!
>
>here are some filenames that fail:
0123456789012345
>BewerbungF�rAnw altsb�ro.doc
>Graphik01Marken identit�t.sxd
>SkriptumzumSemi narF�hren.doc
>WieTeamseffizie ntwerdenk�nnen.doc
0123456789012345
>but otoh these work:
>WerbeK�rntnerBa llonwerbung.sxw
>Vo 08 - 29. M�r z 2001.pdf
>Tsch�ranKirche. jpg
>V�lkermarktKirc heGross.jpg
>
Even though both file sets contain umlauts, or perhaps more accurately extended ASCII
chartacters, there is something distinctive in the "failure" set: the umlauts/extended
characters appear after the 15th character. If you are using REISER4_LARGE_KEYS, the
first fifteen characters will be shifted into the second and third key elements with
the final key el containing the hash of the remaining characters
key = { [dirhash], [hash_bit+fibre_bits+1st 7 chars], [next 8 chars], [hash] }
Code in fs/reiser4/kassign.c assembles the key and uses your chosen hash, R5 being the
default. If you created the files without failure, could read/opened them okay but
then FSCK reported problems, could this point to a difference in the hash code (w.r.t.
extended ASCII)? I'm on holiday now, so cannot check to see if this suspicion holds
any water.
David
p.s. One other possibility is that there is some extended ASCII variance in the the
fibration code, but this seems unlikely.
