[Libburn] Re: Derek: Patch proposal after your recent decisions

[scdbackup at gmx.net]

Hi,

> >  It is not urgent to augment off_t to 64 bit unless you want
> >  to introduce it quickly for clarity reasons.
> 
> Libburn can't currently handle more than 99 minutes in a track, since 
> that's the CD limit.  That makes big files rather uninteresting at this 
> point.  This issue will lie dormant as a comment in a file somewhere until 
> the real need arises.

I am nearly finished with the overview.
We got not very many problem spots with bytecount int.

The number of spots with sectorcount int is much larger
but those will only make trouble with 4 TB media.
(To be expected in about 15 to 20 years.)

Some functions are too obscure for my little brain.
You will get a list of them and have to check yourself
wether there are fat bytecounts involved.


> Don't you dare trap SIGABRT in the front end! :)

Currently i have to. Temporarily, of course, and only
until the drive gets into state BURN_DRIVE_IDLE.
Afterwards cdrskin delivers a nice non-zero exit.


> If an assert is thrown, it's a mission critical bug and someone needs to 
> fix some code.  (Or the hardware acted in a really flakey way and we need 
> to know how to work around it.  heh.)

No assert event will pass unnoticed by the user of cdrskin.
The abort procedure is loud. Dozens of messages saying essentially
  cdrskin: ABORT : <It is done when it is done. Be patient.>
and finally
  cdrskin: ABORT : Program done. Even if you do not see a shell prompt.


> It might be nice to have some kind of softer assert() that still reports 
> line number and failed expression, but also makes sure the drive returns 
> to a sane state.

Yes. It would be nice if libburn could take care of
not leaving the drive endlessly waiting.
Proper signal handling with threads is still a riddle
to me. For the purpose of cdrskin i found solutions
but there are still scenarios for which i can hardly
imagine to get happy with threads.


The problem with ill sized files will hopefully
be eased by the int-to-off_t transition. But as long as we
use 32 bit off_t there will always be files which return
-1 on fstat() due to >4 GB of size.
These files are unusable with libburn and deserve some kind
of abort. I will probably make cdrskin test input files
for successful lstat() before i allow them to hit libburn.

All in all, i believe a fake 0-size is better than an
abort in the  get_size()  function.


> All this code is in CVS now, but I hope to see a simpler get_size as soon 
> as we add the right #defines to make off_t play 64 bit all the time.

With 32 bit we would be able to raise the size ban toi
4 GB minus 800 MB. You might also decide that your code will
not need a computation reserve of 800 MB and raise it even
a bit more.
But essentially this waits for the 64 bit move.


> Is the whitelist your only out of tree patch now?

Among the submitted ideas, it is the last one remaining.

The main obstacle currently seems to be the decision
about the future meaning of 
  burn_drive_info.location
and wether we need a
  burn_drive_info.drive_id
in order to achieve a unique and sufficiently persistent
drive address.
(This does not only affect the wish to isolate from
 unfriendly drives but also cdrskin's method of addressing
 a drive via a long time persistent preconfigured address.)

The actual way of implementation is a less important
issue and might be easily changed after a while
if the first choice turns out to be suboptimal.

My favorite implementation would still be a whitelist
directly settable by the application and no new
burn_drive_scan_single() function. None of my other
ideas on that topic is that straight and versatile.
I just love it. {:)


As soon as cdrskin can make use of the CVS version i will
check about half a dozen workarounds wether they are still
needed. I will report to you.
Next i will annoy you with a list of minor flaws and 
enhancement wishes which i hold back until the important
changes are done. :))

Then there are two big wishes which i cannot fulfill myself.
Not even as a provisory patch:

- a write mode that demands no size prediction.
  (Like cdrecord -data -tao )

- a function which is equivalent to cdrecord -abort and
  makes drives usable again which fell victim to an
  incompletely handled libburn abort. cdrskin does its
  best to prevent this, but it still can happen.


All other of my wishes are currently assigned to Santa Claus.


Have a nice day :)

Thomas