On Sat, 10 May 2014 08:11:40 +0200
"Thomas Schmitt" wrote:
> kern/48787 can be counted as a successful one.
> kern/48797 demonstrates that i need to free myself more from
> expectations which occupied my mind when studying isofs of
> a different kernel.
> Thanks to Martin Husemann for posing the
Hi,
> A PR (Problem Report) in the kern category with an attached unified
> diff would seem adequate if you cannot commit the changes yourself.
I am glad that others will filter my proposals.
kern/48787 can be counted as a successful one.
kern/48797 demonstrates that i need to free myself more f
On Tue, 06 May 2014 12:20:53 +0200
"Thomas Schmitt" wrote:
> How to properly submit them ?
A PR (Problem Report) in the kern category with an attached unified
diff would seem adequate if you cannot commit the changes yourself.
Sorry if that is already obvious to you.
Unfortunately I'm not perso
Hi,
i think i found answers to my questions.
- The inode computation in isodirino() is not necessarily faulty.
Possibly i misunderstood the meaning of ECMA-119,
"9.4.2 Extended Attribute Record length".
- The inode numbers (which currently are byte addresses of
directory records) can be sc
Hi,
i am exploring a bug in fs/cd9660.
A fix seems straightforward after i found its 32 bit rollover
trigger in the code.
But my exploration raises questions:
- Is the inode computation in sys/fs/cd9660/cd9660_node.c:isodirino()
faulty (additionally to its rollover) ?
- Are the inode numbers
