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
On Sat, 10 May 2014 08:11:40 +0200
Thomas Schmitt scdbac...@gmx.net 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
On Tue, 06 May 2014 12:20:53 +0200
Thomas Schmitt scdbac...@gmx.net 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.
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
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
