On 2010-03-04 at 14:53:25 [+0100], Ingo Weinhold <ingo_weinhold@xxxxxx> wrote: > On 2010-03-04 at 13:08:49 [+0100], Stephan Assmus <superstippi@xxxxxx> > wrote: > > On 2010-03-04 at 10:20:31 [+0100], Ingo Weinhold <ingo_weinhold@xxxxxx> > > wrote: > > > BTW, generally I'm not very fond of the development strategy to apply > > > fixes > > > before understanding a problem. > > > > Basically, I just wanted to be able to boot Haiku after upgrading. Instead > > of > > just applying the fix locally, I thought it's better to commit it, so that > > whoever has a clue what change may have caused this -- either who worked > > on > > it last or who has an understanding of the code -- is becomming aware of > > the > > problem. I know it would be nice if I digged into the code to understand > > what's happening, but chances are I would waste precious time, while the > > effect of me commiting the quick fix *could* make somebody else go "yes, > > of > > course!"... > > Without a ticket or at least a TODO and probably no one who feels primarily > responsible (I wrote the module initially and I don't; Axel introduced the > variable block size support; Michael made the most recent changes) there's a > good chance that this will simply slip by. > > > What's so bad about commiting a two line fix if the worst that > > can happen is that nobody else cares? > > Let me play devil's advocate: The 0 block size causes a partition's offset > to > be computed incorrectly which causes the user's data to be overwritten at a > later point. The change, by preventing the early crash, enables the > destructive behavior. > > Yes, unlikely scenario, but that's not my point anyway. Symptom-fixing is > just poor development practice that lowers the code quality. The partition table will not be used when a partition returns false in CheckLayout(). I've made the change thinking I would actually not be able to boot still. The only thing I can think of is that partition scanning happens twice. Best regards, -Stephan