Bug 344392

I suspect that 'Burn Image' tool expects ISO9660 image and does not recognize/support IEC 13346 (UDF) ones.

I just found out that UDFtools don't support UDF 2.5, nor UDF 2.6. I assume that K3b is also having problem handling ISO images containing UDF 2.5.

I wonder, do we actually need support for UDF 2.5 file system if we have an ISO image containing one? Couldn't growisofs or K3b just "dd" data from a BD50 ISO image to a BD burner?

This starts to look like a feature request. :| Also, K3b's error report should be more informative when it comes to failing to handle UDF 2.5, especially when it claims "support for Blu-Ray disks".

After inquiring about this at Cdrtools user support and CD-record (cdwrite) mailing lists, I'm confident that this is a bug in K3b.

Linux has several tools which can burn ANY image to ANY media - no questions asked. It is K3b's fault that its "Burn Image" module considers perfectly normal BD50 ISO image "unusable" and doesn't invoke appropriate command in order to complete operation that can otherwise be done in command line.

After inquiring about this at Cdrtools user support and CD-record (cdwrite) mailing lists, I'm confident that this is a bug in K3b.

Linux has several tools which can burn ANY image to ANY media - no questions asked. It is K3b's fault that its "Burn Image" module considers perfectly normal BD50 ISO image "unusable" and doesn't invoke appropriate command in order to complete operation that can otherwise be done in command line.

After inquiring about this at Cdrtools user support and CD-record (cdwrite) mailing lists, I'm confident that this is a bug in K3b.

Linux has several tools which can burn ANY image to ANY media - no questions asked. It is K3b's fault that its "Burn Image" module considers perfectly normal BD50 ISO image "unusable" and doesn't invoke appropriate command in order to complete operation that can otherwise be done in command line.

I have the same problem. Also, this happens with any UDF image, not only BD50. Infact I'm trying with two dvd images.
ISO9660 images work as expected.

This is on K3b 2.0.2

*** This bug has been marked as a duplicate of bug 257602 ***

I doubt that the problem described here is a duplicate of
https://bugs.kde.org/show_bug.cgi?id=257602

257602 bemoans the lack of a free Blu-ray video mastering tool which puts
out UDF 2.5 or later.
The bug ireport here is about the suspicion that K3B insists in particular
image formats like ISO 9660 and rejects UDF.

I did not find an online repository of K3B upstream. So i looked into
Debians source tree and think that the suspicion gets confirmed in
function (C++tapeworm)::slotUpdateImage
http://sources.debian.net/src/k3b/2.0.3a-2/src/misc/k3bimagewritingdialog.cpp/?hl=517#L517
First d->foundImageType = IMAGE_UNKNOWN; then it looks for ISO 9660,
for "cdrecord clone image" (binary file accompanied by .toc file),
for a CDRWIN .cue file, and has a TODO comment for "cdrdao tocfile".
If none matches, then the image gets the complaint
  "Seems not to be a usable image"

The motivation for the curiosity seems to be the desire to interpret
structured image descriptions like .toc and .cue, which shall not be
written onto medium but rather tell what data to put where on the medium.

--------------------------------------------------------------------

A brutal hack and proof of concept would be to default IMAGE_UNKNOWN
to IMAGE_ISO:

            d->foundImageType = IMAGE_ISO;
            d->imageFile = path;

instead of

            K3b::ListViewItem* item = new K3b::ListViewItem( m_infoView, m_infoView->lastItem(),
                                     i18n("Seems not to be a usable image") );

and to delete the else-clause before the case of known image type:

-        else {
+        {
              // remember as recent image

If this works in the further course of K3B processing, then one could
make the hack permanent. I.e. write unknown images as ISOs.

It might be, nevertheless, that other K3B parts interpret IMAGE_ISO
not only as the order to copy plainly and unaltered but also as
promise that indeed an ISO 9660 superblock and directory tree are
present in the image.
Relying on such a promise would of course yield failure.

If such a promise/expectation exists or if one just wants to implement
it neatly, then one should split all occurences of IMAGE_ISO into those
which just indicate plain image copying and those which really indicate
an ISO 9660 filesystem.
The list of occurences is finite:
  https://codesearch.debian.net/search?q=package%3Ak3b+IMAGE_ISO

A new enum value in
  http://sources.debian.net/src/k3b/2.0.3a-2/src/misc/k3bimagewritingdialog.h/?hl=79#L79
could then be IMAGE_RAW, indicating that it's not an ISO but nevertheless
shall be copied as if it was one.

Thomas is right, this is not a duplicate of bug 257602 and yes, K3B complains about particular image format/size which doesn't have anything to do with a file system that image contains. K3B nor Linux doesn't need to have support for particular file system in order to wright an image that contains it.

I had a look at the spots where Debian's source search finds IMAGE_ISO.

Whether IMAGE_RAW is really needed seems to depend only on the tolerance 
towards the size test in
  http://sources.debian.net/src/k3b/2.0.3a-2/src/misc/k3bimagewritingdialog.cpp/?hl=463#L463
If isoFs() or isoFs.open() throw an exception then it might be necessary
to skip this test.

In this case it would be necessary to introduce IMAGE_RAW or let
IMAGE_UNKNOWN take over the role of IMAGE_RAW.
It seem, though, that IMAGE_UNKNOWN also serves as "Image Unsuitable".
So one better introduces a new value.

--------------------------------------------------------------------------

  http://sources.debian.net/src/k3b/2.0.3a-2/src/misc/k3bimagewritingdialog.cpp/?hl=887#L887
would be ok for IMAGE_RAW, too. I.e.
    if( currentImageType() == IMAGE_ISO || currentImageType() == IMAGE_RAW) {

  http://sources.debian.net/src/k3b/2.0.3a-2/src/misc/k3bimagewritingdialog.cpp/?hl=244#L244
  http://sources.debian.net/src/k3b/2.0.3a-2/src/misc/k3bimagewritingdialog.cpp/?hl=249#L249
would need mapping and reverse mapping for IMAGE_RAW.
Actually the existing text "Plain data image" would rather match IMAGE_RAW
than IMAGE_ISO.

  http://sources.debian.net/src/k3b/2.0.3a-2/src/misc/k3bimagewritingdialog.cpp/?hl=1087#L1087
would need a display text for IMAGE_RAW. Like "opaque".
  http://sources.debian.net/src/k3b/2.0.3a-2/src/misc/k3bimagewritingdialog.cpp/?hl=1048#L1048
would then need a case "opaque" and make use of the reverse mapping
defined by L249.

  http://sources.debian.net/src/k3b/2.0.3a-2/src/misc/k3bimagewritingdialog.cpp/?hl=845#L845
would have to allow growisofs for IMAGE_RAW as for IMAGE_ISO.

  http://sources.debian.net/src/k3b/2.0.3a-2/src/misc/k3bimagewritingdialog.cpp/?hl=858#L858
one would have to add IMAGE_RAW to the "||" list.

  http://sources.debian.net/src/k3b/2.0.3a-2/src/misc/k3bimagewritingdialog.cpp/?hl=867#L867
Same as L858.

  http://sources.debian.net/src/k3b/2.0.3a-2/src/misc/k3bimagewritingdialog.cpp/?hl=874#L874
Same as L858.

  http://sources.debian.net/src/k3b/2.0.3a-2/src/misc/k3bimagewritingdialog.cpp/?hl=548#L548
must stay as is, because it determines whether the file is really an
ISO 9660 filesystem image. It will thus determine the difference between
IMAGE_ISO and IMAGE_RAW.

  http://sources.debian.net/src/k3b/2.0.3a-2/src/misc/k3bimagewritingdialog.h/?hl=81#L81
would define the new enum value IMAGE_RAW.

Git commit 54173816164c825f077e8288b628e550b51ddccb by Leslie Zhai.
Committed on 07/09/2016 at 02:44.
Pushed by lesliezhai into branch 'image-raw'.

Introduce a new image type RAW.

M  +11   -2    src/misc/k3bimagewritingdialog.cpp

http://commits.kde.org/k3b/54173816164c825f077e8288b628e550b51ddccb

Hi Thomas,

> I did not find an online repository of K3B upstream.

UPSTREAM repos is https://quickgit.kde.org/?p=k3b.git and mirror is https://github.com/KDE/k3b

> A new enum value in could then be IMAGE_RAW, indicating that it's not an ISO but nevertheless shall be copied as if it was one

I am reading carefully about your implementation about IMAGE_RAW. and please rebase your patch for image-raw branch https://github.com/KDE/k3b/tree/image-raw thanks a lot ;-)

Regards,
Leslie Zhai

Git commit f33af3b96454e302b722285e532aba7d11ad478e by Leslie Zhai.
Committed on 07/09/2016 at 03:54.
Pushed by lesliezhai into branch 'image-raw'.

Treat unusable image as raw.

M  +1    -1    CMakeLists.txt
M  +16   -7    src/misc/k3bimagewritingdialog.cpp

http://commits.kde.org/k3b/f33af3b96454e302b722285e532aba7d11ad478e

Hi,

Leslie Zhai:
> I am reading carefully about your implementation about IMAGE_RAW. and please
> rebase your patch for image-raw branch

Well, i did not implement anything but only inspected the situation
and made a rough plan what would need a change.
I am running neither KDE nor Gnome on my workstation. Building K3B
from source would start a big endeavor on its own.

But i will from now on study that branch (maybe still using Debian
code search, because searching "IMAGE_ISO" in https://quickgit.kde.org/
yields no match).

Let's see whether i find something to nitpick:
-------------------------------------------------------------------------
Line 473 of k3bimagewritingdialog.cpp:

    d->comboImageType->addItem(i18n("Optical disc media"));

I would rather call it "ISO 9660 filesystem image".

I is not an optical medium but rather shall get onto optical medium.
Albeit ISO 9660 (and its predecessor High Sierra) was announced as
the filesystem for CD-ROM media, ISO 9660 has long escaped that cage.
It is as read-only filesystem very well suited for backup and archiving.
In its role as bootable filesystem it has conquered USB sticks and
memory cards.

-------------------------------------------------------------------------
Line 707:

    case IMAGE_RAW:
    case IMAGE_ISO:
    {
        K3b::Iso9660 isoFs( d->imageFile );
        if( isoFs.open() ) {
            ....
        }

I proposed to introduce IMAGE_RAW in order to be able to skip this test
for size. So there should be an if around it:

    case IMAGE_RAW:
    case IMAGE_ISO:
    {
        if ( d->currentImageType() == IMAGE_ISO ) {
            K3b::Iso9660 isoFs( d->imageFile );
            if( isoFs.open() ) {
                ....
            }
        }

Has it been tested already that

    K3b::Iso9660ImageWritingJob* job_ = new K3b::Iso9660ImageWritingJob( &dlg );

works with non ISO 9660 images ?

-------------------------------------------------------------------------
Line 871:

        if (KMessageBox::questionYesNo(this,
                                       i18n("Seems not to be a usable image, do you want to treat it as RAW?"),
                                       i18n("Unkown image type")) == KMessageBox::Yes) {

The text is somewhat misleading, especially since "raw" has an old
meaning in the context of CD burning.

I would rather state
  "Type of image file is not recognizable. Do you want to burn it anyway ?"

-------------------------------------------------------------------------
Line 938:

You removed the case  d->currentImageType() == IMAGE_UNKNOWN .

I am not sure whether IMAGE_UNKNOWN can reach this code. Nevertheless
we would need a source code review to assert that it cannot.

So i'd cowardly keep IMAGE_UNKNOWN in the "||" list.

-------------------------------------------------------------------------

Have a nice day :)

Thomas

Git commit 585067b15d1d3b0d875e092c775f1925e2ba270f by Leslie Zhai.
Committed on 08/09/2016 at 01:09.
Pushed by lesliezhai into branch 'image-raw'.

Prepare for code review.

M  +16   -12   src/misc/k3bimagewritingdialog.cpp

http://commits.kde.org/k3b/585067b15d1d3b0d875e092c775f1925e2ba270f

Hi Thomas,

Please review it https://git.reviewboard.kde.org/r/128860/

>  because searching "IMAGE_ISO" in https://quickgit.kde.org/ yields no match
Perhaps the mirror GitHub provided such feature as Debian's website?

Hi Marcus,

Could you test image-raw branch for k3b https://github.com/KDE/k3b/tree/image-raw
I do *NOT* have BD50 (Blu-ray double layer) ISO image, or can you provide some URL for testing, thanks a lot!

Regards,
Leslie Zhai

Hi,

Leslie Zhai wrote:
> Please review it https://git.reviewboard.kde.org/r/128860/

I see a box "Testing Done" but no place to state that i did a code
review but did not test.

Shall i write: "Code reviewed but not tested" ?


> I do *NOT* have BD50 (Blu-ray double layer) ISO image,

The problem is neither about the size nor about the medium.
So you could create any non-ISO image file:

  dd if=/dev/zero bs=1M count=100 of=my_100mb_test.img

and use the CD emulator as target device.


Nitpicks:
-------------------------------------------------------------------

The comment

  // set a wanted media type (DVD/BD -> only ISO)

riddled me already when i looked at the code for the first time.

I believe it wants to say that if the image is not IMAGE_ISO, IMAGE_RAW,
or IMAGE_UNKNOWN, then it is a structured CD image description which
cannot be interpreted for DVD or BD media.
So the wanted medium type is  MEDIA_WRITABLE_CD  in this case, and
any medium type for ISO, RAW, and UNKNOWN.

Maybe one should change it to

  // set a wanted media type
  // some image types can be put on any medium, some only on CD

-------------------------------------------------------------------

I still have scruples about the type name "raw" in lines 1152

    else if (imageType == "raw")

and 1200:
                     imageType = "raw";

In man cdrecord (or man wodim) there are lots of references to "raw"
in the sense that CD sector metadata are provided by the input data
of the burn program. A CD sector has 98 * (24 + 8 + 1) = 3234 bytes.
CD-Audio uses 98 * 24 = 2352 for payload. The rest is C1,C2 checksums
and 98 subchannel bytes. CD-ROM uses 2048 for payload. The rest is
filled with more meta-info about the CD sector. Normally we send only
the 2048 bytes to the drive which then computes the meta data.
In "raw" write mode cdrecord sends some or all of the meta-data too.

But this is not what we mean with "raw" image.
So the user should get to see a different word when IMAGE_RAW is being
processed.

(One could argue that IMAGE_RAW should be IMAGE_PLAIN and the text
 should be "plain".
 If i had thought of the raw-raw nomenclature collision i had
 proposed a different macro name. But "IMAGE_RAW" will only be seen
 by programmers, whom i suppose to easily find out that IMAGE_RAW
 is not an image for cdrecord -raw.
)

-------------------------------------------------------------------

Elsewise the changeset looks good to me.
Testing will tell whether it suffices to solve the problem.

Have a nice day :)

Thomas

Hi Thomas,

> Shall i write: "Code reviewed but not tested" ?

You are welcome ;-)

Please click 'Review' to review the patch: https://pbs.twimg.com/media/Cr0S7SqUAAQ5Evo.jpg
You can click 'Expand All' to be familiar with KDE's review process https://git.reviewboard.kde.org/r/128444/

> dd if=/dev/zero bs=1M count=100 of=my_100mb_test.img

I will test it!

> Nitpicks

I am carefully read it, and perhaps you can use KDE's reviewboard to review and comment line by line, please also see https://git.reviewboard.kde.org/r/128444/

Regards,
Leslie Zhai

Hi Thomas,

CDEmu might has strict image test! when I try to cdemu load 0 ~/my_100mb_test.img, it thrown such error:

ERROR: Failed to load image: net.sf.cdemu.CDEmuDaemon.errorMirage.ParserError: No parser can handle the image file!

Regards,
Leslie Zhai

Git commit 3d21bdca2a9ec4ef2d6226991118ba0e3f09a45a by Leslie Zhai.
Committed on 08/09/2016 at 08:29.
Pushed by lesliezhai into branch 'image-raw'.

Fix as Thomas suggested.

M  +7    -6    src/misc/k3bimagewritingdialog.cpp

http://commits.kde.org/k3b/3d21bdca2a9ec4ef2d6226991118ba0e3f09a45a

Hi Thomas,

Updated https://git.reviewboard.kde.org/r/128860/ and it is better to use Reviewboard for reviewing the patch ;-)

Regards,
Leslie Zhai

Hi,

Leslie Zhai wrote:
> Please click 'Review' to review the patch:
> You can click 'Expand All' to be familiar with KDE's review process

Probably i do not see any text fields to fill because i am not logged in
and my bugs.kde.org account does not work.
Registering now as non-robot ...

After login i see a tab "Review" which brings me to a page with 
checkbox "Ship it" and editable text box "Edit header".

I begin to read the online documentation.
If you have instructions for me how to operate it, i would be glad
to follow them.


> CDEmu might has strict image test! when I try to cdemu load 0
> ~/my_100mb_test.img, it thrown such error:

my_100mb_test.img shall not emulate the medium. It shall be copied
onto the emulated medium.

I assume CDEmu has means to create a simulated CD or DVD.
(Did not find a user manual yet.)
This emulated drive and medium would then be the CD drive for the
K3B test. In K3B you select my_100mb_test.img as image file to be
burned.

Have a nice day :)

Thomas

Hi,

i reviewed the whole patch as "Looks good to me".
Since i see no problematic details i think i can skip for now learning
how to comment on single lines. (Tell me if i shall add more info to
the review.)


You need to get a DVD drive. Last year i bought an LG GH24NSC0 for
12.95 EUR. Blu-ray burners still cost around 80 EUR. My newest is
ASUS BW-16D1HT and works well.

Next you'd need a few DVD-RW media, because they are re-usable and can
assume both main roles of optical media: sequential and overwritable.
Switch by dvd+rw-format: no extra option for making overwritable,
option -blank for making sequential, option -blank=full to make it
ready for sequential multi-session.
(-blank[=full] has to be repeated before each sequential re-use.
 Overwritable media can be re-used without formatting them again.
 Formatting and -blank=full last as long as a full capaity write run.)

DVD+RW are more reliable than DVD-RW, but they cannot be written in
sequential state. DVD-RW can be used like DVD-R and quite like DVD+R
or unformatted BD-R.

Have a nice day :)

Thomas

Hi Thomas,

> my_100mb_test.img shall not emulate the medium. It shall be copied onto the emulated medium.

I am stupid ;P I wrongly loaded the virt.img A.K.A my_100mb_test.img, and right now the correct testcase PASS https://pbs.twimg.com/media/Cr39ZYEVYAUylmE.jpg

> Tell me if i shall add more info to the review.

The official Reviewboard doc is very helpful https://www.reviewboard.org/docs/manual/2.5/users/reviews/reviewing-diffs/

and you can play with the demo to be familiar with it http://demo.reviewboard.org/r/

> You need to get a DVD drive

I will try to update my 'Test enviroment' ;-) http://www.leetcode.cn/2016/08/k3b.html

Regards,
Leslie Zhai

Hi,

i wanted to paste to following text into the "Edit header" field
of https://git.reviewboard.kde.org/r/128860/.

But neither the paste function of the window manager nor the paste
menu item of Firefox puts the X selection into the browser field.
Further i always have to disable Javascript when using Debian
code search and enable it before git.reviewboard.kde.org is willing
to communicate with me.

I am getting too old for this modern stuff, i fear.

----------------------------------------------------------------
Review text:
----------------------------------------------------------------

The green "Success" text in the screenshot is a reason to cheer.

While digging in the code i found in
   libk3b / jobs / k3biso9660imagewritingjob.cpp
line 340:

   if( m_simulate )
        return i18n("Simulating ISO 9660 Image");
    else
        return ( i18n("Burning ISO 9660 Image");

Did you see pacifier texts or a headline stating "ISO 9660" ?

Not really understanding how variable "d" enters the context of
the functions and to what type it points, i have no clue whether
one can inquire d->foundImageType or whether currentImageType()
is in reach to avoid the text "ISO 9660" in case of not IMAGE_ISO.

----------------------------------------------------------------
End of review text.
----------------------------------------------------------------

Have a nice day :)

Thomas

Hi Leslie Zhai, Thomas Schmitt,

I have been reading this post.

"K3b" is the most loved CD/DVD/Blu-Ray application for Linux Mint users, including me. If there are updates and or upgrades to this wonderful application, how can Linux Mint users install it on 32-bit and 64-bit systems on Linux Mint versions 17.x based on Ubuntu 14.04  or Linux Mint version 18 based on Ubuntu 16.04? Are there any easy to install and use Linux ".deb" files, or a PPA perhaps, that we can use to install these upgrades? Or, do we have to compile it, and if so, could you please detail those instructions?

Also, since you are actively updating "K3b", I have another feature and or request. Can you do this, or should I create another "KDE bug - feature" request for the modification and or update to the "checksum" aspect of burning and or verifying ".iso"  images to include a more current  "sha256" checksum value, and maybe an option (auto or not) for comparing that to an existing "sha256sum.txt" file that is in the same folder (directory).

Thank you,
Phil D.
KDE User: phdsrq@gmail.com

Linux Mint forum user: phd21
phd21mint@gmail.com

Hi,

Phil wrote:
> Are there any easy to install and use Linux ".deb" files

Well, as soon as it becomes a released feature of K3B, one may ask
pkg-kde-extras@lists.alioth.debian.org for packaging, or file a
Debian bug against package "k3b" requesting it.
Debian's package info is at https://tracker.debian.org/pkg/k3b .

Maybe https://launchpad.net/~kubuntu-members as mentioned on 
https://launchpad.net/ubuntu/+source/k3b would be willing to make 
a shortcut.

> hould I create another "KDE bug - feature" [...]
> verifying ".iso"  images to include a more current  "sha256" checksum

I guess the rules here require that we discuss this in a different
bug report thread.
For transport and storage security, MD5 suffices. The probability of
a false match is far less than the earth being hit by a 10 km asteroid
within the next microsecond. If you don't fear that, then there is no 
need to fear accidential MD5 match.

Have a nice day :)

Thomas

Hi Thomas,

Sorry for late reply, my child fever badly ;-(

> Further i always have to disable Javascript

Yes! javascript developers rock the world now as they argued: sort of nodejs ;-) 

> Did you see pacifier texts or a headline stating "ISO 9660"

I post here https://forum.isoft-linux.org/viewtopic.php?f=3&t=47

> Not really understanding how variable "d" enters the context of the functions and to what type it points

D-Pointer https://wiki.qt.io/D-Pointer and I will double check the text "ISO 9660"

Hi Phil,

> Or, do we have to compile it, and if so, could you please detail those instructions?

Please have a look at http://www.leetcode.cn/2016/08/k3b.html about Dependence and Build

> or should I create another "KDE bug - feature" request for the modification

Yes! please follow the KDE process style, bug report first ;-)

Regards,
Leslie Zhai

Hi,

Leslie Zhai wrote:
> D-Pointer https://wiki.qt.io/D-Pointer

Looks like somebody had to work around some consequences of the
decision to use C++. (Oh if only Bjarne Stroustrup had a real life
back in the 1980s !)


> headline stating "ISO 9660"
> https://forum.isoft-linux.org/viewtopic.php?f=3&t=47

Yep. The "Writing Data Project (virt)" window says "ISO 9660 Filesystem".
But that is not the text i see in k3biso9660imagewritingjob.cpp
"Simulating ISO 9660 Image" and ""Burning ISO 9660 Image".

Question is where this comes from and how to provide the information
about ImageWritingDialog.foundImageType at that place.


Phil wrote:
> should I create another "KDE bug - feature" request

If i shall join that discussion. i'd need a pointer to the thread
by email: scdbackup@gmx.net
(Google finds me places where people say "xorriso", "libburn", or
 "growisofs". But "K3B" yields just too many hits per day.)


Have a nice day :)

Thomas

Hi Thomas,

> the decision to use C++ (Oh if only Bjarne Stroustrup had a real life back in the 1980s !)

Yes! and even there are a lot of c++0x or c++14 style in KDE projects, for example, KWin: https://github.com/KDE/kwin/blob/master/workspace.cpp#L369

> But that is not the text i see in k3biso9660imagewritingjob.cpp

Yes! there are only copy/format project use JobProgressDialog (with jobDescription), but ImageWritingDialog is inherited by InteractionDialog, so you can not see the "Simulating ISO 9660 Image" or ""Burning ISO 9660 Image" jobDescription.

> But "K3B" yields just too many hits per day

KDE bug system, mailing list, reviewboard, and phabricator automatically send a lot of emails... so I use gmail ;P

Regards,
Leslie Zhai

> but ImageWritingDialog is inherited by InteractionDialog

inherited from, sorry typo...

(In reply to Thomas Schmitt from comment #29)
> Hi,
> 
> Leslie Zhai wrote:
> > D-Pointer https://wiki.qt.io/D-Pointer
> 
> Looks like somebody had to work around some consequences of the
> decision to use C++. (Oh if only Bjarne Stroustrup had a real life
> back in the 1980s !)
> 
> 
> > headline stating "ISO 9660"
> > https://forum.isoft-linux.org/viewtopic.php?f=3&t=47
> 
> Yep. The "Writing Data Project (virt)" window says "ISO 9660 Filesystem".
> But that is not the text i see in k3biso9660imagewritingjob.cpp
> "Simulating ISO 9660 Image" and ""Burning ISO 9660 Image".
> 
> Question is where this comes from and how to provide the information
> about ImageWritingDialog.foundImageType at that place.
> 
> 
> Phil wrote:
> > should I create another "KDE bug - feature" request
> 
> If i shall join that discussion. i'd need a pointer to the thread
> by email: scdbackup@gmx.net
> (Google finds me places where people say "xorriso", "libburn", or
>  "growisofs". But "K3B" yields just too many hits per day.)
> 
> 
> Have a nice day :)
> 
> Thomas

Dear Thomas Schmitt,

Thank you for your replies.

If I read your comments properly, you seemed to want to join in on this K3b feature request, so here is the link to that KDE Bug feature request:

I also forwarded an email to your email address.     

Bug 360184 - k3b should offer option to select either md5 sum or sha256 when loading dvd iso 
https://bugs.kde.org/show_bug.cgi?id=360184 

You have a nice day as well :-)  .

Best Regards,

Phil

*** Bug 387765 has been marked as a duplicate of this bug. ***