Description of problem:
I have dragged an mpeg to k3b. Despite k3b claiming that there was
6.1Mb free and allowing the burn without a warning, the debug output
is claiming that the file was too large.
If I use a number of files which doesn't exceed around 3.6Gb, the burn
Version-Release number of selected component (if applicable):
k3b - 0.11.12-2
mkisofs - 2.01.0.a34-1
Always - I have quite a few DVD beer mats!
Steps to Reproduce:
1. Drag a file around 4.2Gb into k3b
2. Attempt to burn
k3b does not issue any warnings about the final size and starts the burn
Either warn the user of the over size file and not allow the burn, or
work burn the DVD correctly
Created attachment 102964 [details]
Debug output from k3b
This is the debug information from k3b. It shows that either k3b is not
listening to mkisofs or that mkisofs is getting itself annoyed.
According the DVD standard, a type 5 DVD should be able to take upto 4.8Gb of
material, therefore a 4.4Gb file should have no problems in being burned.
I've been sort of following this on fedora-test-list, thought it was
time to jump in:
I believe this is a fundamental limitation of iso9660, not a problem
with k3b/growisofs/mkisofs. If you download it and read the spec:
(note ecma-119 *is* iso9660)
you'll notice in section 9.1.4 (p. 39 of the pdf) that a 32-bit value
is specified for the data length (file size) in the directory record.
So you can represent 2^32 different sizes, namely 0 - (2^32)-1.
(Interestingly enough, I just did some testing, and mkisofs seems to
put the limit at (2^32)-2... bug?)
Anyway, there is a solution to this problem; use the UDF filesystem
instead of iso9660. (Note, not in addition to; a UDF/iso9660 hybrid
disk will have all the restrictions of iso9660.)
Maybe we need to turn this into an RFE for UDF support in Fedora?
Of course, the reason it's not included already may be that UDF is
file is too large!