- priority: 5 --> 8
There's a small logic error in AMapRebuild
(allocmap.cc, about line 130), while the logic for
merging blocks before and after has code to correctly
handle link propagation, the logic is slightly
incomplete in the 'overlap' case..
There's an if statement to check for link consistency:
// complete overlap here \(segment already added?\) if \(prev >= 0 && \(blk \!= ch->start || \(ch->link >= 0 && prev \!= ch->link\)\)\) \{ return \(-1\); \}
But this needs to be followed immediately by the
following logic to correctly assign a link if it wasn't
there before:
// Possible prior link.. if \(prev >= 0 && \(blk == ch->start && \(ch->link <
0))) {
ch->link = prev;
}
To understand why this is necessary consider the
following situation (It sounds far fetched but it's
happened to me twice this weekend)
1) There's a rip unit comprising several files...
2) The rip unit is split at least once using a link record
3) One of the splits is such that there's a file change
in the first
block of the next allocation run..
(e.g. file 1 goes from blocks 136676 - 136712, then
from 138555-138555, file 2 goes from 138555 to 138580)
4) Some time after loading, the TOC is rearranged such
that file 2 occurs BEFORE file 1.
What happens is file 2 establishes 138555 - 138580
WITHOUT a previous link.. then the link record which
consists only of 138555 comes along, and is flagged as
an overlap, but the link it's carrying never gets
stored.. The change above remedies this situation
correctly.