Red Hat Bugzilla – Bug 122453
mkisofs won't allow large files
Last modified: 2007-11-30 17:10:42 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040124
Description of problem:
I'm attempting to burn a file a little larger than 4GB to a DVD using
growisofs (which in turn uses mkisofs.)
Here's the commandline I'm using:
/usr/bin/growisofs -Z /dev/scd0 \
-V "$BARCODE" -volset "$VOLSET" \
-A "$APPLICATION_ID" -P "$PUBLISHER_ID" -p "$PREPARER_ID" \
-sysid "$SYSTEM_ID" -volset-size 1 -volset-seqno 1 \
When I run it I get the following error from mkisofs:
Executing 'mkisofs -V TEST -volset TEST -A mkkadvd v1.0 -P Company
Name -p user -sysid system.name -volset-size 1
-volset-seqno 1 -udf . |
builtin_dd of=/dev/scd0 obs=32k seek=0'
mkisofs: Value too large for defined data type. File ./foo is
too large - ignoring
/dev/scd0: engaging DVD-R DAO upon user request...
I've also tested further with mkisofs-2.01-0.a27.2 (the rpm currently
in fc2-test) and get the exact same error. From all the information
I've read it should be possible to burn a file this size in UDF format.
The exact size of the file in question is 4337607728 bytes.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Execute the growisofs command above against a directory containing
a large file (in excess of 4GB).
Actual Results: mkisofs reports an error: Value too large for defined
data type. File ./foo is too large - ignoring
Expected Results: The file should have been burned to the DVD.
Although I'm pretty sure this is not growisofs' fault the version of
* growisofs by <email@example.com>, version 5.13,
front-ending to mkisofs: mkisofs 2.01a27 (i686-pc-linux-gnu)
From what I understand of section 9 of the ISO 9660 standard (
) the data length of a file is described by a 32 bit number, thus
files larger then ~4GB can not exist on a iso image. I therefor
suggest we close this bug as a 'notabug'
Yes, but I was using the -udf option. I had hoped this would then
cause mkisofs to generate a ISO 13346/ECMA-167/UDF v2.01 filesystem...
in this spec the data length of a file is descript by an unsigned 64
bit number. I guess if you decide the -udf option != ISO 13346 then
you can argue it's not a bug... If nothing else the -udf option should
then be changed to -udfbridge if what is really meant is that it is
the ISO9660/UDF hybrid (UDF v1.02?) format.
well, the man page hints you in that direction:
"UDF support is currently in alpha status and for this reason, it is
not possible to create UDF only images."
Please ask the author about full udf support...
Btw, there are udftools, which can create a correct udf file system