Hi, Rebecca N. Palmer wrote: > Package: src:linux
There seems to be no such package name. I got the source by apt-get install linux-source so i guess it would be ok to use that package name. > 'affects' means it will appear in your package's bug list but be marked as > linux's bug. It does not keep xorriso (or cdrkit's genisoimage) from working properly. It just fails to work properly with flawless output from those programs. Does that qualify for 'affects' ? Henrique de Moraes Holschuh wrote: > Ugh. Yeah, that code looks broken at first glance. Two sins: It hits the innocent and it defaces its victims. > Maybe it should instead drop the long name, and return the ISOFS name, > instead. This might reduce the probability of a name collision, but can still collide with some short Rock Ridge name. Better would probably be a hash text derived from all available information about the file, which is not very much at that level of code, i fear. E.g. a SHA256 of the full really oversized name, plus some constant salt, should reduce the probability to an acceptable level and still show reproducible names. But the actually needed fix is the protection of the innocent. > However, one has to check the code throughoutly to ensure it can deal with > the 255-bytes size. Will dive into the code and already began to read http://kernel-handbook.alioth.debian.org Maybe i can make experiments with s/254/256/ and/or with truncation to exactly the assumed maximum size. > Opening a bug report on bugzilla.kernel.org for 'isofs' would be the typical > way to go about it, I guess. Shall i do already now or better after i exhausted my code reading skills and/or managed to get a kernel running with s/254/256/ ? > OTOH, it is a >10-year old bug, so there are some kudos and credit to be > proud of for anyone that fixes it :-) Is there a find-the-oldest-bug contest ? And is the list open for mere oddities, too ? (I have some Linux timestamp peculiarities of which i really don't know whether i shall replay them in libisofs.) > The code in fs/isofs/rock.c looks like it has lots of cowebs and some > bitrot, though. The equivalents in FreeBSD, OpenSolaris, and NetBSD are even more dusty. Solaris still calls it "High Sierra". To our luck there are userland tools to read ISO 9660 independently of the kernels. Among them is my xorriso. Have a nice day :) Thomas
