[k3b] [Bug 379268] Importing previous session does nothing (version 17.04.0)

[Thomas Schmitt]

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

--- Comment #27 from Thomas Schmitt <scdbackup at gmx.net> ---
Hi,

K3B indeed wrote the second session:

  READ TRACK INFORMATION[#2]:
   Track State:           complete incremental
   Track Start Address:   1991984*2KB
   Free Blocks:           0*2KB
   Track Size:            175104*2KB
   Last Recorded Address: 2167087*2KB

The allocated block range was completely written: 1991984 + 175104 = 2167088.
So all looks well from the view of the medium.


> > - Do you see the files of both sessions if you force Linux mount to use
> >   the ISO 9660 aspect of the medium ?

> Yes, when I mount UDF disc on which K3b has written two session,
> now files of all sessions have appropriate size and are readable.

Just to be sure because this is crucial for the following diagnosis:
You see all files with mount -t iso9660. You see the files of session 1
crippled if mounted without -t or with -t udf. Right ?

In this case it is not the fault of K3B but rather of genisoimage.
(At least genisoimage is in charge if you did not install cdrtools by
 Joerg Schilling which is not provided by Debian since 2006.)

UDF offers its own appendability features. Obviously genisoimage does not
make proper use of them.
They would not easily be compatible with ISO 9660 and its multi-session
method, which is the main topic of genisoimage.

But obviously your kernel and my kernel react in a different way.
Mine mounts session 1 and thus misses the newer files. Yours seems to
mount session 2 but fails to make the connection from directory tree
to the older file content.
(So bug two and three in our preliminary counting are only one bug:
 genisoimage does not properly combine multi-session and UDF.)


I myself studied ECMA-167 and UDF-2.60, concluded that it is darn
complicated and offers no features which ISO 9660 + Rock Ridge couldn't
easily provide, and thus decided to snub it in libisofs development.

It's only good for video players which cannot play anything but UDF 1.02.

This imposes a problem with DVD video and appendability anyways:
  https://en.wikipedia.org/wiki/Universal_Disk_Format
states that video players expect UDF 1.02 whereas the VAT tables for
appendabilty were added only in version 1.5.
So even if you find a program that does UDF VAT it might be that your
video player does not understand it. (And if you do not have a player
which needs UDF, why have mkisofs style UDF at all ?)

Have a nice day :)

Thomas

-- 
You are receiving this mail because:
You are the assignee for the bug.