[Libburn] Patch to enable arbitrary input fd (updated 2nd submission)

[Derek Foreman]

On Sat, 11 Feb 2006, scdbackup at gmx.net wrote:

> Hi,
>
> i finally grasped what you meant with putting the size into .data .
> Sorry for not knowing what my new constructor does exactly.
>
>
> Yes, struct burn_source_file in file.h is a good place to
> put (type_to_find) fixed_size .
> Provided it is your intention to restrict fixed size setting to
> sources of type  burn_source_file .
>
> In that case, what about this :
>
> struct burn_source_file
> {
>        int datafd;
>        type_to_find fixed_data_size;
>        int subfd;
> };

I was thinking a new struct burn_source_fd.  It might be that we need a 
new read function too...

I think fixed_data_size isn't meaningful for all data sources, as the rest 
of the info directly in burn_source is.  I don't think it's useful for 
files on disc - I think we already have a way to select only part of an 
input file in the track structures (for things like burning a single large 
wav file as multiple tracks, etc).

Is there a need for fixed_data_size on sources where functions like stat 
can be used?  Does it really need to be universal?

> Then i would propose something like:
>
> static int file_size(struct burn_source *source)
> {
>        struct stat buf;
>        struct burn_source_file *fs = source->data;
>        type_to_find size;
>
>        if(fs->fixed_data_size > 0) {
>                 size = fs->fixed_data_size;
>        } else {
>                 fstat(fs->datafd, &buf);
>                 size = buf.st_size;
>        }
>        /* ??? what to do in case of size >= 2 GB ? */
>        /* ??? return -1 , return 0 ? */
>        return (int) size;
> }
>
> Unless the type of file_size() is changed to the type_to_find
> there will be the need to invent an error return and a need to
> interpret it by the callers.
> Alternatively one could abort, but as application programmer
> i would perceive this as somewhat rough.
>
> This need is independent of my patch proposals.
> Files of >= 2 GB are common.

I think the return type should be changed to something other than int. 
What that type should be is still negotiable as per the other thread.

The real concern here tho, is what happens if the file is deleted after 
the front end decides it's ok, and before we stat it.  We still need to 
return some kind of error...