Version: 1.0 (using KDE KDE 3.5.6) Installed from: Debian testing/unstable Packages OS: Linux csights@fastmail.fm has reported the following on the Debian bug tracker (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=419628): K3b should use the genisoimage switch "-allow-limited-size" when adding files larger than 2GiB to a DVD. If I try to add the file "Quantum4_1a.bak" which is 2.2GB k3b fails to burn and says (in debugging output): mkisofs ----------------------- File /tmp/quantum/Quantum4_1a.bak is larger than 2GiB. File /tmp/quantum/Quantum4_1a.bak is larger than 2GiB. -allow-limited-size was not specified. There is no way do represent this file size. Aborting. -allow-limited-size was not specified. There is no way do represent this file size. Aborting. However, if I type at the command line: genisoimage -allow-limited-size Quantum4_1a.bak > out.iso I get a valid out.iso. (I mounted it on loopback and saw that it had Quantum4_1a.bak in it.)
Great! Now it begins. cdrtools and cdrkit finally become two separate things I have to support! This sucks. NEVER cut the debugging output of K3b. Now important information is missing. Which version of genisoimage is this?
I'm about to open a genisoimage bug with debian to make them aware of the problem as well. Maybe it can be fixed in genisoimage instead? k3b debugging output: System ----------------------- K3b Version: 1.0 KDE Version: 3.5.5 QT Version: 3.3.7 Kernel: 2.6.19.3 Devices ----------------------- SONY DVD RW DRU-510A 1.1a (/dev/hdc, ) [CD-R, CD-RW, CD-ROM, DVD-ROM, DVD-R, DVD-RW, DVD+R, DVD+RW] [DVD-ROM, DVD-R Sequential, DVD-RW Restricted Overwrite, DVD-RW Sequential, DVD+RW, DVD+R, CD-ROM, CD-R, CD-RW] [SAO, TAO, RAW, SAO/R96R, RAW/R96R, Restricted Overwrite] CD-ROM Drive/F5D 2.42 (/dev/hdd, ) [CD-ROM] [Error] [None] K3bIsoImager ----------------------- mkisofs print size result: 0 (0 bytes) Used versions ----------------------- mkisofs: 1.1.4 mkisofs ----------------------- File /tmp/quantum/Quantum4_1a.bak is larger than 2GiB. File /tmp/quantum/Quantum4_1a.bak is larger than 2GiB. -allow-limited-size was not specified. There is no way do represent this file size. Aborting. -allow-limited-size was not specified. There is no way do represent this file size. Aborting. mkisofs calculate size command: ----------------------- /usr/bin/X11/genisoimage -gui -graft-points -print-size -quiet -volid K3b data project -volset -appid K3B THE CD KREATOR (C) 1998-2006 SEBASTIAN TRUEG AND THE K3B TEAM -publisher -preparer -sysid LINUX -abstract -copyright -biblio -volset-size 1 -volset-seqno 1 -sort /tmp/kde-cwseysoxRYVO/k3bZ8vb7a.tmp -rational-rock -hide-list /tmp/kde-cwseysoxRYVO/k3bqu7FRb.tmp -joliet -joliet-long -hide-joliet-list /tmp/kde-cwseysoxRYVO/k3bymge1b.tmp -no-cache-inodes -udf -full-iso9660-filenames -iso-level 3 -path-list /tmp/kde-cwseysoxRYVO/k3bPdiPPb.tmp
cross-reference debian bug #419719 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=419719
SVN commit 655084 by trueg: * Added configure option to disable the cdrecord suid root check * Added support for the stupid new genisoimage parameter -allow-limited-size. The cdrkit guys introduced this silently without even mentioning it in the Changelog although it breaks writing files bigger than 2GB. BUG: 144323 M +7 -0 configure.in.bot M +14 -0 configure.in.in M +7 -1 libk3b/projects/datacd/k3bisoimager.cpp M +4 -0 src/k3bsystemproblemdialog.cpp --- trunk/extragear/multimedia/k3b/configure.in.bot #655083:655084 @@ -8,6 +8,13 @@ echo "" fi +if test "$cdrecord_suid_root" != "yes"; then + echo "" + echo "K3b - Suid root test for cdrecord, cdrdao, and wodim deactivated" + echo "K3b - This is NOT recommended although it might work out fine ;)" + echo "" +fi + if $have_taglib; then echo "K3b - Audio meta data reading with Taglib: yes" else --- trunk/extragear/multimedia/k3b/configure.in.in #655083:655084 @@ -63,6 +63,20 @@ AM_CONDITIONAL(with_k3bsetup1, [test x$compile_k3bsetup = xyes]) +cdrecord_suid_root=yes +AC_ARG_WITH( + cdrecord-suid-root, + AS_HELP_STRING( + [--without-cdrecord-suid-root], + [enable or disable K3b's suid root check for cdrecord/cdrdao/wodim (default=enabled)]), + [cdrecord_suid_root=$withval], + [cdrecord_suid_root=yes] +) +if test x$cdrecord_suid_root = xyes; then + AC_DEFINE(CDRECORD_SUID_ROOT_CHECK,1,[defined if K3b should check cdrecord for suid root]) +fi + + # Extra SCSI support libs can go in CAM_LIB, and are linked into # libk3bdevice. For Linux, nothing is needed. FreeBSD requires -lcam # (which is in base, so no test is needed). --- trunk/extragear/multimedia/k3b/libk3b/projects/datacd/k3bisoimager.cpp #655083:655084 @@ -678,10 +678,16 @@ } } - if( filesGreaterThan2Gb ) + if( filesGreaterThan2Gb ) { emit infoMessage( i18n("Found files bigger than 2 GB. These files will only be fully accessible if mounted with UDF."), WARNING ); + // in genisoimage 1.1.3 "they" silently introduced this aweful parameter + if ( d->mkisofsBin->hasFeature( "genisoimage" ) && d->mkisofsBin->version >= K3bVersion( 1, 1, 3 ) ) { + *m_process << "-allow-limited-size"; + } + } + bool udf = m_doc->isoOptions().createUdf(); if( !udf && filesGreaterThan2Gb ) { emit infoMessage( i18n("Enabling UDF extension."), INFO ); --- trunk/extragear/multimedia/k3b/src/k3bsystemproblemdialog.cpp #655083:655084 @@ -222,6 +222,7 @@ QString::null, true ) ); } +#ifdef CDRECORD_SUID_ROOT_CHECK else if( !k3bcore->externalBinManager()->binObject( "cdrecord" )->hasFeature( "suidroot" ) && getuid() != 0 ) // not root problems.append( K3bSystemProblem( K3bSystemProblem::CRITICAL, i18n("%1 will be run without root privileges").arg("cdrecord"), @@ -234,6 +235,7 @@ "true when using SuSE's resmgr."), QString::null, true ) ); +#endif // CDRECORD_SUID_ROOT_CHECK #endif } @@ -246,6 +248,7 @@ } else { #ifdef Q_OS_LINUX +#ifdef CDRECORD_SUID_ROOT_CHECK if( !k3bcore->externalBinManager()->binObject( "cdrdao" )->hasFeature( "suidroot" ) && getuid() != 0 ) problems.append( K3bSystemProblem( K3bSystemProblem::CRITICAL, i18n("%1 will be run without root privileges").arg("cdrdao"), @@ -254,6 +257,7 @@ "overall stability of the burning process."), QString::null, true ) ); +#endif // CDRECORD_SUID_ROOT_CHECK #endif } }
Sebastian, please, please, please, if some things are broken that have been working before, drop us a note on debburn-devel@lists.alioth.debian.org. Your input will be appreciated. Not knowing about the problems is as bad as having them. I realize that the last change made the support for file sizes 2gb <= x <4gb unusable. Sorry for that, but there have been technical considerations for this decission. Basically, everything beyond 2**31 bytes is a gray zone since a signed 32bit integer is used there. Recent mkisofs versions may have allowed you to have files sizes up to 2*32-1 but I doubt that this is beyound common sense and I would not expect such immages to be portable. Do you think that people have being using file sizes 2gb<=n<4gb much in the last years, so much that it might be worty to enable that again? About the new option itself... well, having this file size bypass means that a truncated filesize is stored in isofs which may be bad. So it seems to better let decide people whether to use this feature or not, they need to be aware of that. Therefore, another -allow- option in the style of others with similar character has been introduced. Sorry about insufficient changelog, but at least the error message was self-explaining. Do you agree? Currently, it is not a big deal if you mount the created disk explicitely with -t udf or let the mount command decide with the right priority (mount -t udf,iso9660), Windows XP prefers UDF anyway where found. But it may be a bad suprise on regular Linux system which try isofs+RR as the first filesystem type. We understand your concerns about not wanting to support divergent CLI between cdrkit and cdrtools... but neither do we like enabling a dangerous option by default. For the 2..4gb area, it might be considered though, just for the sake of compatibility. From the GUI view, I would place an option like "Ignore possible incorrect ISO9660" which would enable all that stuff, adding the new option for genisoimage immediately, or checking file sizes and maybe rejecting files when using mkisofs.
> Sebastian, please, please, please, if some things are broken that have been > working before, drop us a note on debburn-devel lists alioth debian org > Your input will be appreciated. Not knowing about the problems is as bad as > having them. Well, it is very annoying if you change the API of genisoimage in a minor release without even mentioning it in the ChangeLog. Please don't do that. At least name it 1.2 or even better 2.0 for that. But I already patched K3b. Now it uses the -allow-imited-size option on projects with files bigger than 2gb and genisoimage >= 1.1.3. > I realize that the last change made the support for file sizes 2gb <= x > <4gb unusable. Sorry for that, but there have been technical considerations > for this decission. Basically, everything beyond 2**31 bytes is a gray zone > since a signed 32bit integer is used there. Recent mkisofs versions may > have allowed you to have files sizes up to 2*32-1 but I doubt that this is > beyound common sense and I would not expect such immages to be portable. > > Do you think that people have being using file sizes 2gb<=n<4gb much in the > last years, so much that it might be worty to enable that again? Well, not that many probably, I had three of four "bug" reports. > About the new option itself... well, having this file size bypass means > that a truncated filesize is stored in isofs which may be bad. So it seems > to better let decide people whether to use this feature or not, they need > to be aware of that. Therefore, another -allow- option in the style of > others with similar character has been introduced. Sorry about insufficient > changelog, but at least the error message was self-explaining. > > Do you agree? Yes, but an error message is no good for a GUI client. ;) And I agree with you on the option, don't get me wrong. It was just the way you introduced it. Maybe next time if you change sth like that you could drop me a line and I could implement it in K3b right away, so cdrkit and K3b newest versions would work together properly again. > Currently, it is not a big deal if you mount the created disk explicitely > with -t udf or let the mount command decide with the right priority (mount > -t udf,iso9660), Windows XP prefers UDF anyway where found. But it may be a > bad suprise on regular Linux system which try isofs+RR as the first > filesystem type. K3b warns about the UDF issue. That is all I can do since users just want to burn those files. Even more, many complain about not being able to burn files bigger than 4gb. > We understand your concerns about not wanting to support divergent CLI > between cdrkit and cdrtools... but neither do we like enabling a dangerous > option by default. For the 2..4gb area, it might be considered though, just > for the sake of compatibility. Not necessary. Like I said: it is already in svn and will be part of 1.0.1 which I will release in the next days. > From the GUI view, I would place an option like "Ignore possible incorrect > ISO9660" which would enable all that stuff, adding the new option for > genisoimage immediately, or checking file sizes and maybe rejecting files > when using mkisofs. People don't care about that most of the time so another option is not a good idea. I think a warning message which can be ignored is the way to go. :)
I have found some trouble with the 0.12.17 version of k3b writing large files about 4 GB in size - the DVDs are not read by Windows at all. Other DVDs written without these large files are ready by Windows properly. Do you think my problem is related to this bug?