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 \ -udf \ /directory/containing/large/file 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): mkisofs-2.01-0.a19.2 How reproducible: Always 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. Additional info: Although I'm pretty sure this is not growisofs' fault the version of growisofs is: growisofs -version * growisofs by <appro.se>, version 5.13, front-ending to mkisofs: mkisofs 2.01a27 (i686-pc-linux-gnu) from dvd+rw-tools-5.13.4.7.4-1.
From what I understand of section 9 of the ISO 9660 standard ( http://www.ecma-international.org/publications/files/ecma-st/ECMA-119.pdf ) 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