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. * 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. Have a nice day :) Thomas
