First results from using IsoStream for content reading

[scdbackup]

I made use of the IsoStream? interface for data content reading. All in all it was able to fulfill my needs up to now. A first use case is the new xorriso option

-compare disk_path iso_rr_path

which mainly serves as test for correctness of reading. Comparison will have its more valuable use cases together with runs on complete subtrees.

---

But some pitfalls appeared.

1) iso_stream_read() returns failure if one requests a maximum buffer count which is larger than the number of remaining bytes in the IsoStream?. This drops any data which would be still available. I assume this is a consequence of the buffering loop which tries to do several reads to get the buffer full.

I would assume that this additional code in ifs_read() could provide a simple solution:

    }

+   if(count > data->info.st_size - data->data.offset)
+       count = data->info.st_size - data->data.offset;
+   if (count <= 0)
+       return 0;

    while (read < count && data->data.offset < data->info.st_size) {

If it is not possible to return the available number of bytes and delay the EOF return up to the next call of iso_stream_read(), then this behavior needs to be documented in the API. One can inquire the size before reading.

2) My xorriso adapter to data reading seems to become a parallel implementation of what is done at image generation time. I want to see the same content as is written into the new file object during a modificating run from old to new image. Regardless whether it comes from old image or from filesystem.

The problem becomes obvious by the fact that i need to explore or guess what libisofs will do in case of file size change between adding the image node and data reading. The same with read errors of any kind.

It would be helpful if libisofs would offer a level of data reading which is guaranteed to deliver the same byte string as would be copied during image generation. (If image generation would happen right now.)

It would nevertheless suffice if the exact behavior of image generation reading is published in the API description of iso_stream_read().

3) There is a grammatical typo widespread in libisofs. Past tense of "to open" is "opened", not "openned". This includes also ISO_FILE_NOT_OPENNED.

[vreixo]

iso_stream_read() returns failure if one requests a maximum buffer count which is larger than the number of remaining bytes in the IsoStream??. This drops any data which would be still available.

Are you sure? I've tried it (take a look at demo/iso_cat) and it works ok. I've reviewed the code and I haven't seen anything strange. It should work. It works for me. Where did you get the problem? How can I reproduce it?

If it is not possible to return the available number of bytes and delay the EOF return up to the next call of iso_stream_read()

it is possible. For example, a Stram with 500 available bytes:

first iso_stream_read(stream, buf, 1200) returns 500 next iso_stream_read(stream, buf, 1200) will return 0 (EOF)

this should work ok.

The problem becomes obvious by the fact that i need to explore or guess what libisofs will do in case of file size change between adding the image node and data reading. The same with read errors of any kind.

it either fills the image with 0s (on read errors or if the file is smaller than expected), or truncates the file if it has grown.

Take a look at filesrc_read() and filesrc_writer_write_data() in filesrc.c.

There is a grammatical typo widespread in libisofs. Past tense of "to open" is "opened", not "openned". This includes also ISO_FILE_NOT_OPENNED.

ups, ugly. What should we do? deprecate ISO_FILE_NOT_OPENNED and define ISO_FILE_NOT_OPENED seems the better alternative...

[scdbackup]

Are you sure? I've tried it (take a look at demo/iso_cat)

I tried to reproduce it but up to now it fails to fail.

A few days ago i got truncated reading results with return value from iso_stream_read(). By help of gdb i stepped into libisofs and saw ifs_read() return 0.

Since then i changed a lot in xorriso's reader and did not commit to SVN inbetween.

I now disabled the size consideration in xorriso and hope to see the effect again under some circumstances.

If so: i will report. If not: the better.

This includes also ISO_FILE_NOT_OPENNED.

ups, ugly. What should we do? deprecate ISO_FILE_NOT_OPENNED and define ISO_FILE_NOT_OPENED seems the better alternative...

Yes. Define a new symbol ISO_FILE_NOT_OPENED and keep the old ISO_FILE_NOT_OPENNED nevertheless. I would have them as immediate neighbors in libisofs.h so their difference and similarity becomes obvious.