Bugzilla – Bug 80583
k3b says "success" but burning fails because mkisofs returns wrong return code
Last modified: 2006-09-07 14:49:21 UTC
When I try to burn files (size 4G) to a DVD, k3b tells that the writing successfully finished but the media is empty. In the debugging output you can read: /usr/bin/mkisofs: Value too large for defined data type. File /backup/server1-backupaa is too large - ignoring k3b shouldn't ignore the error from mkisofs and warn the user about this problem.
how can you be so certain, mkisofs returned an error?
as root and as user: --8<-- g212:~ # mkisofs -o /tmp/foo.iso /backup/foo && echo $? INFO: UTF-8 character encoding detected by locale settings. Assuming UTF-8 encoded filenames on source filesystem, use -input-charset to override. mkisofs: Value too large for defined data type. File /backup/foo is too large - ignoring Total translation table size: 0 Total rockridge attributes bytes: 0 Total directory bytes: 0 Path table size(bytes): 10 Max brk space used 0 174 extents written (0 MB) 0 -->8-- The problem is a unsigned-long in mkisofs. Reassigning to Vladimir Nadvornik.
AFAIK the iso9660 filesystem does not support large files. The message from mkisofs is probably considered to be just a warning. The iso image is created correctly, only some files are ignored and you get warnings about it. Files with insufficient permissions or other problems are handled in similar way. Changing return value could break compatibility with previous versions. I think the best fix would be to add a new commandline option which causes mkisofs fail immediately, when some file is ignored. Is it OK for you? Other possibility would be to add some check to k3b, when the file is added.
The maximum file size is 2 GB for a DVD-Video file and 4 GB for a data file. Only if a file is above 4G it should fail. If there is 100% loss of data then it does not make sense at all so there is no need to add commandline . Adrian, coolo what about k3b?
I guess, k3b shouldn't let you add 4GB files then. But we won't fix that for SLES9
Correction - its 2^8 and unsigned - there is no limit at all.
another correction 2^64
3.7G file is handled OK, the limit is 4G. Thorsten, do you want a fix for SLES9?
Sorry, but for me it is not clear what needs to be fixed in which way.
Change return value of mkisofs if a file over 4G is ignored. There might be some more precise conditions.
So, this is nothing new, it does also not work in SL9.3? I'm in favor of not changing this for SLES9.
It is the same in all mkisofs versions. So it is WONTFIX for SLES9. Changing product to SL 10.0 I will try to make a better error handling in mkisofs. coolo, I still think it should be fixed in k3b too.
*** Bug 104060 has been marked as a duplicate of this bug. ***
I just submitted patched mkisofs that fails with error on files > 4GB. It prevents writting broken images, however k3b should handle this better.
*** Bug 118295 has been marked as a duplicate of this bug. ***
trying to gain Stephan's attention
The k3b of 10.1 does not allow adding of files greater than 4GB to projects.
> I just submitted patched mkisofs that fails with error on files > 4GB. Vladimir, for which products? I see an cdrecord update for SL 10.0 but not for SLES 9? The original report was against SLES9 before you changed it to SL 10.0.
the point is that it doesn't have to be fixed for sles9.