https://bugs.kde.org/show_bug.cgi?id=367639

--- Comment #40 from Thomas Schmitt <scdbac...@gmx.net> ---
Hi,

> http://commits.kde.org/k3b/ae0413daf1df44cb2c8c6e88a5b86180f1f52c3a
> libk3b/projects/datacd/k3bisoimager.cpp

Then let's see ...

> +    char* in_image = "/dev/fd/0";

This is still wrong.
We need to access the existing ISO 9660 filesystem on the medium.
So this should rather be the path to the drive with the DVD+RW.
(I.e. something like "/dev/sr0" on Linux.)


> +    // Validate file descriptor
> +    if (sscanf(in_image, "/dev/fd/%u", &imgfd) == 1)
> +        imgfd = dup(imgfd);
> +    else

This case should then not occur. (We cannot lseek() on stdin anyway.)


> +        imgfd = open(in_image, O_RDONLY);

This will be in effect.

(For the subsequent code i can just hope that i did not propose too
 much nonsense. It needs to be tested when the path problem is solved.)

I do not see where you throw severe error if m_multiSessionInfo stays
with string value "0,0". This value means that we cannot use the growisofs
emulation of multi-session and that growisofs will raise protest about
-C 0,0. Without -C it would probably just overwrite the existing data
instead of adding new data. Maybe it would complain about -M without -C.

K3B should tell the user that it won't work instead of letting growisofs
or other writers do undesired things or issue cryptic error messages.


> - A generic checker for GrowisofsWriter (growisofs) and IsoImager (mkisofs)

You did not put the rounding stage into a writer specific function.
As it is now, the function in k3bisoimager.cpp  assumes that all writers
behave like growisofs.

So to stay modular (and to give cdrskin a chance to override the values
by its own findings) you should not round in k3bisoimager.cpp but
rather introduce a new writer specific function for all writers.
- The one of growisofs will round up to 16.
- The (future i hope) one of cdrskin would ask cdrskin for its own values
  for the given medium and ISO 9660 filesystem.
- The one of cdrecord would throw error, because i assume that cdrecord
  does not support on DVD+RW a write start address other than 0.

To prepare for cdrskin, the new function should know the path of the
drive's device file (e.g. "/dev/sr0").

Have a nice day :)

Thomas

-- 
You are receiving this mail because:
You are watching all bug changes.

Reply via email to