Re: "Calculated and written ECMA-119 tree end differ" under very specific circumstances

[Thomas Schmitt]

Hi,

the daily update:

Valtteri, please test the currently uploaded xorriso-1.5.5 as announced
yesterday. Its code state is my favorite candidate for the last minute
fix of the half baked release 1.5.4.

  http://www.gnu.org/software/xorriso/xorriso-1.5.5.tar.gz
  MD5 a5e3dc4e0b92be6837f9ed6cbf7f9df5
  Version timestamp :  2021.02.03.115443

-----------------------------------------------------------------------

I found out why the prediction of continuation area use by AAIP needs
to see the prediction of continuation area padding. I.e. why the current
xorriso-1.5.5 is doing it right.

At the end of the prediction, the padding size gets added to the payload
size. But if the AAIP prediction encounters a block boundary, then it
predicts the same padding too.

xorriso-1.5.5 of 2021.02.01.174513 did not show the padding size to
the AAIP prediction. So the predicted write position was not yet aligned
to a block boundary and padding got predicted again.
After a few dozen blocks, this mistake adds up to a wrong prediction of
block counts.

The currently uploaded version 2021.02.03.115443 shows the predicted gap
to the AAIP prediction and thus avoids the second prediction of a padding,
because the block boundary has already been passed.
So prediction and actual writing stay in sync.


I face three alternatives for a fix:

1:
Leave it as in 2021.02.03.115443. Just insert a comment which explains
the situation, as winded and error prone as it is.

2:
Remove the prediction of continuation area padding from the overall
prediction and leave it to the particular predictors to handle the
first padding, as they already handle the possible further paddings.
(This removal would happen in susp_calc_nm_sl_al().)

3:
Like 2 but also remove the counterpart of the overall prediction in
the write pass. The current code does no harm, afaics. But it would be
asymmetric to leave it in. Further it seems to be harmless more by
incident than by aptness of my past self.
(This removal would happen in rrip_get_susp_fields().)

I have tested all three variations here. They all seem to work.

Least invasive is number 1. So i will probably choose this for the
last minute bug fix in libisofs-1.5.4 and for GNU xorriso-1.5.4.pl01.

For the next development cycle i will probably choose number 3.
Most neat, most lean, most courageous.


Have a nice day :)

Thomas