https://bugs.kde.org/show_bug.cgi?id=367639
--- Comment #24 from Thomas Schmitt <scdbac...@gmx.net> --- Hi, > please review it https://git.reviewboard.kde.org/r/128932/ My browser seems not to be ready for the layout or your changeset is much too small. I only see: QStringList ms = d->multiSessionInfo.split(','); if (ms.size() == 2) { if (ms[0] == 0 || ms[1] == "0") { qDebug() << "you don't have to specify -C option, growisofs will construct one for you!"; d->process << "-use-the-force-luke=spare=none"; } else { d->process << "-C" << d->multiSessionInfo; } } where i wonder who is addressed as "you". Other parts of K3B which constructed the d->multiSessionInfo content ? growisofs tolerates a -C option if the second value matches its own perception of medium and ISO 9660 filesystem. https://sources.debian.net/src/dvd%2Brw-tools/7.1-11/growisofs.c/#L3271 } else if (alleged_next_session!=next_session) fprintf (stderr,"%s: -C argument is %s.\n", argv[0],alleged_next_session>=0? "insane":"undefined"), exit(FATAL_START(EINVAL)); You need to pass the same -C value to mkisofs as the one which growisofs will determine (i.e. import growisofs code into K3B and hope that growisofs stays as it is), or you have to force growisofs to use the -C value which you computed more freely and gave to mkisofs. (Possibly/hopefully by growisofs option -use-the-force-luke=seek:N) Do i get it right that if (ms[0] == 0 || ms[1] == "0") { shall catch "-C 0,0" that was determined by K3B ? If so, then K3B has probably seen an overwritable medium. In this case it should have already checked whether an ISO 9660 is present and where it ends. From that end it should have composed d->multiSessionInfo = "0,N" with N being a suitably rounded 2KiB block number after the end of the ISO filesystem. So when multiSessionInfo hits k3bgrowisofswriter.cpp it should be already a usable value and should be forced onto growisofs. As said, the value has to be used with the mkisofs run. Handing it over to growisofs would be a good check to prevent misunderstandings between K3B and growisofs. Better growisofs refuses to start than that it writes an add-on session to the wrong address. Background: -C old_start,new_start tells mkisofs to read the ISO superblock at address old_start and to prepare the output superblock and tree for being written to address new_start. Wrong old_start will yield mkisofs abort due to lack of superblock. Wrong new_start will yield output and no mkisofs error. growisofs will write the output to medium. But then the new session will not be mountable or the directory tree will yield i/o errors and/or wrong data file content. That's because all inner block number fields of the ISO will be wrong. ----------------------------------------------------------------------- My proposal to use -use-the-force-luke=spare=none was only for the case of blank BD-R media. Those will not have d->multiSession set while they are blank, i assume. So in the changeset code the option will not be applied to them. Background: If growisofs is ordered to write to BD-R without option ...spare=none, then it formats them to Pseudo-Overwritable state. Indigestible for libburn and probably for cdrecord. After the first session the BD-R will cause -C 0,0 and thus will need the special processing above. With option ...spare=none, growisofs leaves the BD-R unformatted and plainly writes the first session to it. (At full nominal speed !) Then the BD-R resembles much a written DVD+R. Current K3B will be able to inquire the correct -C values and hopefully perform multi-session as it hopefully does on DVD+R. (Somebody must test, of course.) --------------------------------------------------------------------- I can navigate in quickgit.kde.org quite well. So better point me to code or changesets there. In general i doubt that i can be of much help with K3B implementation details, except checking code which reads info from ISO 9660 filesystems. What i can offer is technical background info and testing of growisofs on re-usable media. I will try to make a demo script with mkisofs and growisofs running separately. Have a nice day :) Thomas -- You are receiving this mail because: You are watching all bug changes.
