On Mon, Jul 9, 2018 at 6:54 AM, Thomas Schmitt <[email protected]> wrote:
> Hi, > > while copying Pete's work from example/isofile.c to example/C++/isofile.cpp > i noticed that the j-loop assumes full blocks in all but the last extent > of a data file. > All blocks get read and written fully. Only the last extent's copy gets > adjusted by ftruncate(3). > > I did not notice this when working on the .c files in ./examples. > Pete, were you aware when you made your changes ? > > > Reasoning why this assumption is very inappropriate currently: > > If we made it, then we would not need to model extents at all. > It would suffice to add to iso9660_stat_t a large integer as ".total_size" > and to deprecate the use of ".size". > Applications would not need to loop over extents but simply loop longer > over the blocks of a single giant extent. > > The assumption itself is quite plausible. I do not know real ISO images > where it would not hold. For ISO producer software it is very natural. > But: It is not in the ISO 9660 specs and it is not in Linux kernel. > > ------------------------------------------------------------------------ > > What does this mean for our current discussion ? > > If we agree to make that assumption, then Pete's proposal can be reduced > to a form which is very convenient for the existing applications. > They would only have to change the use of one struct member. > (ABI would break anyway.) > > If we do not agree to that assumption, then somebody will have to correct > the extent loops in his proposal. > > The assumption makes few sense with my proposal. Either we can do it cheap > or we can do it right. > So i will now adapt the extent loops in ./example and ./test of my branch. > I will give you a note when the first loop is ready for review. > > ------------------------------------------------------------------------ > > Further my proposal still needs two boss decisions, before it could > potentially be accepted: > > * Give the type enmum of iso9660_stat_t a name ? > Currently: No. > Consequence: New API has to simulate anonymous enum values by integers. > My take is to split off iso9660 with no ABI/API changes. Then change API and give the the anonymous enumeration a name. I'm not all that thrilled with savannah as a project hosting system compared to what you get with either github, gitlab, or sourceforge. > * Where to declare semi-public methods of iso_rock_statbuf_t ? > Currently: Declared in iso9660_fs.c and rock.c. Not in any header file. > Consequence: Clumsy. That's what header files are for. > Since we are breaking the API, declare it in rock.h. > > Have a nice day :) > > Thomas > > >
