mkisofs can't handle files over 2^32 bytes

Bug #30033 reported by Grondr
14
Affects Status Importance Assigned to Milestone
cdrtools (Ubuntu)
Fix Released
Medium
Unassigned

Bug Description

In Breezy, 32-bit AMD:

I'm trying to write a DVD consisting of a single large data file (this isn't going to be a viewable DVD---just data). I'm using growisofs to do it, and that uses mkisofs internally. However, mkisofs apparently barfs if the input file is > 2^32 bytes, with "mkisofs: Value too large for defined data type. File [whatever] is too large - ignoring". (Even better, growisofs then just charges ahead, oblivious to the error, hence instantly wasting money by burning a coaster before it can be stopped. And doing -dry-run won't turn this up, because it doesn't really dry-run the mkisofs.)

I see years-old complaints on the net, for various distros, about mkisofs being unable to handle > 2^31-byte files; apparently the value in Ubuntu is now unsigned, but still 32-bit. Given that DVD's hold more than 2^32 bytes, this is a frustrating limitation. (Sure, I can write more then 2^32 bytes to a DVD ISO image, but not if all those bytes are supposed to be in the -same- file.)

Is there any hope that mkisofs will be rewritten with proper largefile support? Is there some other version that I could give to growisofs?

Tnx.

Revision history for this message
Matt Zimmerman (mdz) wrote :

Did you try -udf? iso9660 (the default) doesn't support large files.

Changed in cdrtools:
status: Unconfirmed → Needs Info
Revision history for this message
Pēteris Krišjānis (pecisk-gmail) wrote :

I can also second this bug - this is very annoying, because I have one 4.5 GB large Backup.rar file, and I usually have to deal with such big files. Problem is here that Nautilus CD Burner uses growisofs and that uses mkisofs. In turn, it doesn't give any clue to Nautilus CD Burner about what is gone wrong, just saying that there is problem.

Problem is also that -udf support is claimed alfa level, so it could be not very serious to do burning with it. However, if it could work, growisofs or even Nautilus should call it when some of files are bigger than ISO standard allows.

Revision history for this message
Pēteris Krišjānis (pecisk-gmail) wrote :

I tried mkisofs with -udf flag, but still got the same error:

pecisk@Pecisk:/media/sdb1/PecisStuff$ mkisofs -udf -o dvd.iso DVD/
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 DVD/Rezerve.rar 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 21000
1135 extents written (2 MB)

Revision history for this message
Richard (rd1) wrote :

I also have this bug, resulting from using K3B with default options. I have a 4 GB backup file from a Windows backup tool that I am trying to burn to DVD. There are clearly quite a few people who have had this problem, and it's 100% reproducible and already fixed upstream in development builds, so it would be good to see a fix in Ubuntu - currently this is something that Windows handles without problems.

I'm on Breezy with mkisofs called from k3b. I've attached the debug info generated from k3b.

Package: mkisofs
Version: 4:2.01+01a01-4ubuntu3

There's also a significant GUI bug in k3b here - despite files being skipped by mkisofs, the user is given no warning of this at all.... Luckily there was only one file involved here, so the error was obvious.

Revision history for this message
Richard (rd1) wrote :

Here's the attachment mentioned.

Revision history for this message
karaluh (karaluh) wrote :

Still a problem in feisty

Revision history for this message
Schily (schilling-fokus) wrote :

mkisofs supports "large files" since 2001, but
it did not support multi-extent files and for
this reason, it needed to limit the file size to 4 GB.

As DVDs are 4.3 GB, this was not a big problem before.
Now that cdrecord introduced Blu Ray support, the long
planned multi-extent support was implemented.

mkisofs-2.01.01a32 adds support for files > 4 GB.

Cdrtools-2.01.01a32 will be published early next week,
most likely on Monday, 30th July 2007

See http://cdrecord.berlios.de/

Note that due to a Linux kernel bug, you will currently
not be able to read the complete content of multi-extent
files on Linux.

Revision history for this message
Schily (schilling-fokus) wrote :

Please try the mkisofs package from gutsy/multiverse

This is no longer a missing feature in mkisofs.

Make sure to call mkisofs with -iso-level 3 or -iso-level 4 to allow files >= 4 GB.

Changed in cdrtools:
status: Incomplete → Fix Released
Revision history for this message
Calin Brabandt (calinb-calinb) wrote :

> Please try the mkisofs package from gutsy/multiverse

In PPC Feisty, this results in:

"The following packages have unmet dependencies:
mkisofs: Depends: libc6 (>= 2.6-1) but 2.5-0ubuntu14 is to be installed
E: Broken packages"

Mixing libc from different versions of Ubuntu seems to be an excellent
way to break your system!

Feisty is the current version of Ubuntu. Can't someone fix this feature
there?

Revision history for this message
Pēteris Krišjānis (pecisk-gmail) wrote :

Calin, please fill bug report with request about backporting mkisofs to Feisty. If it will be possible, it will be done.

Revision history for this message
Reinhard Tartler (siretart) wrote : Re: [Bug 30033] Re: mkisofs can't handle files over 2^32 bytes

Calin Brabandt <email address hidden> writes:

>> Please try the mkisofs package from gutsy/multiverse
>
> In PPC Feisty, this results in:
>
> "The following packages have unmet dependencies:
> mkisofs: Depends: libc6 (>= 2.6-1) but 2.5-0ubuntu14 is to be installed
> E: Broken packages"
>
> Mixing libc from different versions of Ubuntu seems to be an excellent
> way to break your system!
>
> Feisty is the current version of Ubuntu. Can't someone fix this feature
> there?

Ok, you can find updated cdrtools packages for feisty here:

https://launchpad.net/~ubuntu-burning/+archive/

Follow the instructions, or download the packages manually by following
the link to the archive.

--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4

Revision history for this message
Calin Brabandt (calinb-calinb) wrote :

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Thanks, Reinhard!

I'm on PPC so I'm not officially supported but, given the cross
architecture nature of the bug reported, I did submit a bug report and
request for a backport of the fix to Feisty.

I'll try building cdrtools_2.01.01a35.orig.tar.gz.

Just as an FYI, I built the berlios.de cdrecord and was able to create
an iso image using the resulting mkisofs. Unfotunately, I could not
burn the image without fatal errors about 2/3 of way through the burn.

http://cdrecord.berlios.de/old/private/cdrecord.html

- -Cal

Reinhard Tartler wrote:
> Calin Brabandt <email address hidden> writes:
>
>>> Please try the mkisofs package from gutsy/multiverse
>> In PPC Feisty, this results in:
>>
>> "The following packages have unmet dependencies:
>> mkisofs: Depends: libc6 (>= 2.6-1) but 2.5-0ubuntu14 is to be installed
>> E: Broken packages"
>>
>> Mixing libc from different versions of Ubuntu seems to be an excellent
>> way to break your system!
>>
>> Feisty is the current version of Ubuntu. Can't someone fix this feature
>> there?
>
> Ok, you can find updated cdrtools packages for feisty here:
>
> https://launchpad.net/~ubuntu-burning/+archive/
>
> Follow the instructions, or download the packages manually by following
> the link to the archive.
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG8sW/TeWuWwscyxERApFEAJ0YunMIB80owVVs5v8sDFV/rTaubQCfQYDs
9qyizP8G5G47vbYQ9ljfdTo=
=dno+
-----END PGP SIGNATURE-----

Revision history for this message
Schily (schilling-fokus) wrote :

If you have problems with burning the data you should send the output
from cdrecord -v to allow to understand what happened.

Revision history for this message
Calin Brabandt (calinb-calinb) wrote :
Download full text (4.6 KiB)

Schily wrote:
> If you have problems with burning the data you should send the output
> from cdrecord -v to allow to understand what happened.
>
Your website says you no longer have time to provide support, which I
very much understand. So thanks very much for your offer of assistance.
 Here is the output.

> calinb@ppc:/opt/schily/bin$ sudo ./cdrecord -v dev=1000,1,0 -speed=2 ~/dvd.iso
> ./cdrecord: No write mode specified.
> ./cdrecord: Asuming -sao mode.
> ./cdrecord: If your drive does not accept -sao, try -tao.
> ./cdrecord: Future versions of cdrecord may have different drive dependent defaults.
> Cdrecord-ProDVD-ProBD-Clone 2.01.01a35 (powerpc-unknown-linux-gnu) Copyright (C) 1995-2007 J�rg Schilling
> TOC Type: 1 = CD-ROM
> scsidev: '1000,1,0'
> scsibus: 1000 target: 1 lun: 0
> Linux sg driver version: 3.5.27
> Using libscg version 'schily-0.9'.
> SCSI buffer size: 64512
> atapi: 1
> Device type : Removable CD-ROM
> Version : 0
> Response Format: 2
> Capabilities :
> Vendor_info : 'MATSHITA'
> Identifikation : 'DVD-R UJ-835F '
> Revision : 'GGND'
> Device seems to be: Generic mmc2 DVD-R/DVD-RW/DVD-RAM.
> Current: DVD+R
> Profile: DVD+R (current)
> Profile: DVD+RW
> Profile: DVD-RW restricted overwrite
> Profile: DVD-RW sequential recording
> Profile: DVD-R sequential recording
> Profile: DVD-ROM
> Profile: CD-RW
> Profile: CD-R
> Profile: CD-ROM
> Using generic SCSI-3/mmc-3 DVD+R driver (mmc_dvdplusr).
> Driver flags : NO-CD DVD MMC-3 SWABAUDIO BURNFREE
> Supported modes: PACKET SAO
> Drive buf size : 1572864 = 1536 KB
> FIFO size : 4194304 = 4096 KB
> Track 01: data 4479 MB
> Total size: 4479 MB = 2293754 sectors
> Current Secsize: 2048
> Blocks total: 2295104 Blocks current: 2295104 Blocks remaining: 1350
> Starting to write CD/DVD/BD at speed 2 in real SAO mode for single session.
> Last chance to quit, starting real write 0 seconds. Operation starts.
> Waiting for reader process to fill input buffer ... input buffer ready.
> Starting new track at sector: 0
> Track 01: 3685 of 4479 MB written (fifo 98%) [buf 98%] 2.5x../cdrecord: Success. write_g1: scsi sendcmd: no error
> CDB: 2A 00 00 1C CB 38 00 00 1F 00
> status: 0x2 (CHECK CONDITION)
> Sense Bytes: F1 00 04 00 1C C8 40 0A 00 39 00 00 03 03 00 00
> Sense Key: 0x4 Hardware Error, deferred error, Segment 0
> Sense Code: 0x03 Qual 0x03 (peripheral device write fault) [No matching qualifier] Fru 0x0
> Sense flags: Blk 1886272 (valid)
> resid: 63488
> cmd finished after 3.406s timeout 100s
>
> write track data: error after 3864641536 bytes
> ./cdrecord: A write error occured.
> ./cdrecord: Please properly read the error message above.
> Writing time: 1238.342s
> Average write speed 2.7x.
> Min drive buffer fill was 16%
> Fixating...
> ./cdrecord: Success. close track/session: scsi sendcmd: no error
> CDB: 5B 01 01 00 00 01 00 00 00 00
> status: 0x2 (CHECK CONDITION)
> Sense Bytes: 70 00 05 00 00 00 00 0A 00 83 00 00 30 05 00 00
> Sense Key: 0x5 Illegal Request, Segment 0
> Sense Code: 0x30 Qual 0x05 (cannot write medium - incompatible format) Fru 0x0
> Sense flags: Blk 0 (not valid)
> cmd finished after 0.002s tim...

Read more...

Revision history for this message
Calin Brabandt (calinb-calinb) wrote :

Schily wrote:
> If you have problems with burning the data you should send the output
> from cdrecord -v to allow to understand what happened.
>
I think we may need to move this new issue (bug?) elsewhere as the
original bug appears to be resolved.

I plugged a Plextor firewire burner into my PPC Mac mini and the burn
completed successfully. Is this a Matshita incompatibility problem?
The Matshita is a common OEM drive in Macs.

Thanks again!

> calinb@ppc:/opt/schily/bin$ sudo ./cdrecord -v dev=0,0,0 -speed=4 ~/dvd.iso
> ./cdrecord: No write mode specified.
> ./cdrecord: Asuming -sao mode.
> ./cdrecord: If your drive does not accept -sao, try -tao.
> ./cdrecord: Future versions of cdrecord may have different drive dependent defaults.
> Cdrecord-ProDVD-ProBD-Clone 2.01.01a35 (powerpc-unknown-linux-gnu) Copyright (C) 1995-2007 J�rg Schilling
> TOC Type: 1 = CD-ROM
> scsidev: '0,0,0'
> scsibus: 0 target: 0 lun: 0
> Linux sg driver version: 3.5.27
> Using libscg version 'schily-0.9'.
> SCSI buffer size: 64512
> atapi: 0
> Device type : Removable CD-ROM
> Version : 0
> Response Format: 1
> Vendor_info : 'PLEXTOR '
> Identifikation : 'DVDR PX-708A2 '
> Revision : '1.03'
> Device seems to be: Generic mmc2 DVD-R/DVD-RW/DVD-RAM.
> Current: DVD+R
> Profile: DVD+R (current)
> Profile: DVD+RW
> Profile: DVD-RW sequential recording
> Profile: DVD-RW restricted overwrite
> Profile: DVD-R sequential recording
> Profile: DVD-ROM
> Profile: CD-RW
> Profile: CD-R
> Profile: CD-ROM
> Using generic SCSI-3/mmc-3 DVD+R driver (mmc_dvdplusr).
> Driver flags : NO-CD DVD MMC-3 SWABAUDIO BURNFREE
> Supported modes: PACKET SAO
> Drive buf size : 6684672 = 6528 KB
> Drive pbuf size: 8388608 = 8192 KB
> Drive DMA Speed: 18753 kB/s 106x CD 13x DVD 4x BD
> FIFO size : 4194304 = 4096 KB
> Track 01: data 4479 MB
> Total size: 4479 MB = 2293754 sectors
> Current Secsize: 2048
> Blocks total: 2295104 Blocks current: 2295104 Blocks remaining: 1350
> Starting to write CD/DVD/BD at speed 4 in real SAO mode for single session.
> Last chance to quit, starting real write 0 seconds. Operation starts.
> Waiting for reader process to fill input buffer ... input buffer ready.
> Starting new track at sector: 0
> Track 01: 4479 of 4479 MB written (fifo 100%) [buf 98%] 4.2x.
> Track 01: Total bytes read/written: 4697608192/4697608192 (2293754 sectors).
> Writing time: 860.134s
> Average write speed 3.9x.
> Min drive buffer fill was 97%
> Fixating...
> Fixating time: 25.167s
> ./cdrecord: fifo had 73993 puts and 73993 gets.
> ./cdrecord: fifo was 0 times empty and 34413 times full, min fill was 59%.

Revision history for this message
Schily (schilling-fokus) wrote :

I needed to write this because I did get too many support mails
from people that suffered from bugs that have been added by Suse or Debian.

I am always open to reports on real bugs.....

Your writer is either defective or unable to deal with the media you
are using.

1) you should always use -v for reports

2) send the cdrecord -atip output for the media

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.