On Sat, 2009-07-25 at 18:56 +0200, Vladimir 'phcoder' Serbinenko wrote: > On Sat, Jul 25, 2009 at 6:36 PM, Robert Millan<r...@aybabtu.com> wrote: > > On Fri, Jul 24, 2009 at 09:24:31PM +0200, Felix Zielcke wrote: > >> + loop = 0; > >> + while (loop < 100000) > >> [...] > >> + if (loop == 100000) > >> + return grub_error (GRUB_ERR_BAD_PART_TABLE, "Corrupted partition > >> table found."); > > > > What does this 100000 represent? It looks like heuristic, but I'm missing > > some context (I'm not familiar with extended partition layout). > It is a heuristic.It's a number bigger than highest number of "sane" > partitions but an amount of iteration which a computer can handle > easily. > I know that it's an arbitrary limit butusing a correct algorithm (e.g. > record all visited extended partitions offsets) would take place > almost uselessly and other solutions risk to have other problems (as > "invisible" partitions)
Let's try to see the complete picture. By the time we get 100000 partitions we are already in trouble, especially if running ls on a slow terminal. Reaching 100000 means we were wrong all along. Links backwards between extended partition entries are more likely to be due to data corruption than due to buggy partitoning tools. OK, if you want, let's support up to 10 backward links. That's more than enough. I would hate to get caught in another discussion about minor issues when we have a real problem in that code. GRUB only follows a single chain of extended partitions rather than a tree of links. I think the whole point in having the Linux extended partition type is to allow it to coexist with an MS-DOS extended partition. That's a realistic scenario, unlike backward links. -- Regards, Pavel Roskin _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
