Re: DVDs created with too large files
> But can a file span multiple extents? The way I read the comment > Gary quoted, it's legal to have an image that is over 2GB in size, > as long as each file inside that image is no larger than 2GB. Careful - the comment was about mkisofs, although it was in the kernel source. It definitely says file*systems* >2GB are legal, otherwise it says mkisofs can't handle single *files* >2GB - that doesn't necessarily mean they're illegal. The comment may also be old and no longer true for current versions of standards. > But then the whole comment seems odd. It looks to me like the > WARNING was added later, and written by Jörg. Yes > That seems to me like > the only logical way to explain why the comment says it's legal, > but the code claims it's illegal to have files that are more than > 2GB in size. You're mixing up file with filesystem here? > so apparently at least someone looked at ISO Level 3 support. I'd > say send a message to linux-kernel and see what they say about > it... Yes, together with a raft of other iso9660 issues :( Perhaps mkisofs is now able to handle files >2GB, the lack of a suitable error when creating the filesystem does suggest so. However, for Linux that's a moot point as Linux doesn't handle >2GB, but mkisofs isn't only used on Linux. Thanks Gary for the warning about that. It should be possible to retrieve the file with isoinfo -x, which doesn't use any filesystem code. Volker -- Volker Kuhlmann is possibly list0570 with the domain in header http://volker.dnsalias.net/ Please do not CC list postings to me.
Re: DVDs created with too large files
At 8:48 PM +0100 11/2/03, Lourens Veen wrote: >On Sun 2 November 2003 19:03, ljknews wrote: >> At 5:27 PM + 11/2/03, Gary Houston wrote: >> >I have been using dvd+rw-tools (5.13.4.7.4) and mkisofs >> > (cdrtools 1.11a29) to write backups to DVD. This generally >> > works. However I encountered a problem when one of the files >> > was 2351679431 bytes in size: the disk was written with no >> > errors reported, but on testing proved to be unreadable to >> > linux 2.4.21. On mounting the disk a warning was reported: >> > >> >Warning: defective CD-ROM. Enabling "cruft" mount option. >> >> "Defective" CD-ROM is a misleading statement. >> "Interchange Level 3 ISO-9660 volumes are not handled by this OS" >> would be more accurate. >> >> >/* >> > * The ISO-9660 filesystem only stores 32 bits for file size. >> >> But the ISO-9660 _standard_ stores 32 bits for the size of each >> _extent_ and there can be a virtually unlimited number of >> _extents_ in a single file at ISO-9660 Interchange Level 3. > >But can a file span multiple extents? Absolutely yes, at ISO-9660 Interchange Level 3. That is the only difference between Interchange Level 3 and lower levels. Note that one therefore must be at Interchange Level 3 to have a file span multiple volumes (and thus to have a file larger than the size of a single volume. > The way I read the comment >Gary quoted, it's legal to have an image that is over 2GB in size, >as long as each file inside that image is no larger than 2GB. That is the case for ISO-9660 Interchange Level 1 and Level 2. > I >haven't actually read the spec though. I have :-)
Re: DVDs created with too large files
> But can a file span multiple extents? The way I read the comment > Gary quoted, it's legal to have an image that is over 2GB in size, > as long as each file inside that image is no larger than 2GB. Careful - the comment was about mkisofs, although it was in the kernel source. It definitely says file*systems* >2GB are legal, otherwise it says mkisofs can't handle single *files* >2GB - that doesn't necessarily mean they're illegal. The comment may also be old and no longer true for current versions of standards. > But then the whole comment seems odd. It looks to me like the > WARNING was added later, and written by Jörg. Yes > That seems to me like > the only logical way to explain why the comment says it's legal, > but the code claims it's illegal to have files that are more than > 2GB in size. You're mixing up file with filesystem here? > so apparently at least someone looked at ISO Level 3 support. I'd > say send a message to linux-kernel and see what they say about > it... Yes, together with a raft of other iso9660 issues :( Perhaps mkisofs is now able to handle files >2GB, the lack of a suitable error when creating the filesystem does suggest so. However, for Linux that's a moot point as Linux doesn't handle >2GB, but mkisofs isn't only used on Linux. Thanks Gary for the warning about that. It should be possible to retrieve the file with isoinfo -x, which doesn't use any filesystem code. Volker -- Volker Kuhlmann is possibly list0570 with the domain in header http://volker.dnsalias.net/ Please do not CC list postings to me. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DVDs created with too large files
At 8:48 PM +0100 11/2/03, Lourens Veen wrote: >On Sun 2 November 2003 19:03, ljknews wrote: >> At 5:27 PM + 11/2/03, Gary Houston wrote: >> >I have been using dvd+rw-tools (5.13.4.7.4) and mkisofs >> > (cdrtools 1.11a29) to write backups to DVD. This generally >> > works. However I encountered a problem when one of the files >> > was 2351679431 bytes in size: the disk was written with no >> > errors reported, but on testing proved to be unreadable to >> > linux 2.4.21. On mounting the disk a warning was reported: >> > >> >Warning: defective CD-ROM. Enabling "cruft" mount option. >> >> "Defective" CD-ROM is a misleading statement. >> "Interchange Level 3 ISO-9660 volumes are not handled by this OS" >> would be more accurate. >> >> >/* >> > * The ISO-9660 filesystem only stores 32 bits for file size. >> >> But the ISO-9660 _standard_ stores 32 bits for the size of each >> _extent_ and there can be a virtually unlimited number of >> _extents_ in a single file at ISO-9660 Interchange Level 3. > >But can a file span multiple extents? Absolutely yes, at ISO-9660 Interchange Level 3. That is the only difference between Interchange Level 3 and lower levels. Note that one therefore must be at Interchange Level 3 to have a file span multiple volumes (and thus to have a file larger than the size of a single volume. > The way I read the comment >Gary quoted, it's legal to have an image that is over 2GB in size, >as long as each file inside that image is no larger than 2GB. That is the case for ISO-9660 Interchange Level 1 and Level 2. > I >haven't actually read the spec though. I have :-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DVDs created with too large files
On Sun 2 November 2003 19:03, ljknews wrote: > At 5:27 PM + 11/2/03, Gary Houston wrote: > >I have been using dvd+rw-tools (5.13.4.7.4) and mkisofs > > (cdrtools 1.11a29) to write backups to DVD. This generally > > works. However I encountered a problem when one of the files > > was 2351679431 bytes in size: the disk was written with no > > errors reported, but on testing proved to be unreadable to > > linux 2.4.21. On mounting the disk a warning was reported: > > > >Warning: defective CD-ROM. Enabling "cruft" mount option. > > "Defective" CD-ROM is a misleading statement. > "Interchange Level 3 ISO-9660 volumes are not handled by this OS" > would be more accurate. > > > /* > > * The ISO-9660 filesystem only stores 32 bits for file size. > > But the ISO-9660 _standard_ stores 32 bits for the size of each > _extent_ and there can be a virtually unlimited number of > _extents_ in a single file at ISO-9660 Interchange Level 3. But can a file span multiple extents? The way I read the comment Gary quoted, it's legal to have an image that is over 2GB in size, as long as each file inside that image is no larger than 2GB. I haven't actually read the spec though. But then the whole comment seems odd. It looks to me like the WARNING was added later, and written by Jörg. That seems to me like the only logical way to explain why the comment says it's legal, but the code claims it's illegal to have files that are more than 2GB in size. Lastly, at the top of the file, there is * 1998 Eric Lammerts - ISO 9660 Level 3 so apparently at least someone looked at ISO Level 3 support. I'd say send a message to linux-kernel and see what they say about it... Lourens -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key
Re: DVDs created with too large files
At 5:27 PM + 11/2/03, Gary Houston wrote: >I have been using dvd+rw-tools (5.13.4.7.4) and mkisofs (cdrtools 1.11a29) >to write backups to DVD. This generally works. However I encountered >a problem when one of the files was 2351679431 bytes in size: the disk >was written with no errors reported, but on testing proved to be unreadable >to linux 2.4.21. On mounting the disk a warning was reported: > >Warning: defective CD-ROM. Enabling "cruft" mount option. "Defective" CD-ROM is a misleading statement. "Interchange Level 3 ISO-9660 volumes are not handled by this OS" would be more accurate. > /* >* The ISO-9660 filesystem only stores 32 bits for file size. But the ISO-9660 _standard_ stores 32 bits for the size of each _extent_ and there can be a virtually unlimited number of _extents_ in a single file at ISO-9660 Interchange Level 3.
Re: DVDs created with too large files
On Sun 2 November 2003 19:03, ljknews wrote: > At 5:27 PM + 11/2/03, Gary Houston wrote: > >I have been using dvd+rw-tools (5.13.4.7.4) and mkisofs > > (cdrtools 1.11a29) to write backups to DVD. This generally > > works. However I encountered a problem when one of the files > > was 2351679431 bytes in size: the disk was written with no > > errors reported, but on testing proved to be unreadable to > > linux 2.4.21. On mounting the disk a warning was reported: > > > >Warning: defective CD-ROM. Enabling "cruft" mount option. > > "Defective" CD-ROM is a misleading statement. > "Interchange Level 3 ISO-9660 volumes are not handled by this OS" > would be more accurate. > > > /* > > * The ISO-9660 filesystem only stores 32 bits for file size. > > But the ISO-9660 _standard_ stores 32 bits for the size of each > _extent_ and there can be a virtually unlimited number of > _extents_ in a single file at ISO-9660 Interchange Level 3. But can a file span multiple extents? The way I read the comment Gary quoted, it's legal to have an image that is over 2GB in size, as long as each file inside that image is no larger than 2GB. I haven't actually read the spec though. But then the whole comment seems odd. It looks to me like the WARNING was added later, and written by Jörg. That seems to me like the only logical way to explain why the comment says it's legal, but the code claims it's illegal to have files that are more than 2GB in size. Lastly, at the top of the file, there is * 1998 Eric Lammerts - ISO 9660 Level 3 so apparently at least someone looked at ISO Level 3 support. I'd say send a message to linux-kernel and see what they say about it... Lourens -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DVDs created with too large files
At 5:27 PM + 11/2/03, Gary Houston wrote: >I have been using dvd+rw-tools (5.13.4.7.4) and mkisofs (cdrtools 1.11a29) >to write backups to DVD. This generally works. However I encountered >a problem when one of the files was 2351679431 bytes in size: the disk >was written with no errors reported, but on testing proved to be unreadable >to linux 2.4.21. On mounting the disk a warning was reported: > >Warning: defective CD-ROM. Enabling "cruft" mount option. "Defective" CD-ROM is a misleading statement. "Interchange Level 3 ISO-9660 volumes are not handled by this OS" would be more accurate. > /* >* The ISO-9660 filesystem only stores 32 bits for file size. But the ISO-9660 _standard_ stores 32 bits for the size of each _extent_ and there can be a virtually unlimited number of _extents_ in a single file at ISO-9660 Interchange Level 3. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
DVDs created with too large files
I have been using dvd+rw-tools (5.13.4.7.4) and mkisofs (cdrtools 1.11a29)
to write backups to DVD. This generally works. However I encountered
a problem when one of the files was 2351679431 bytes in size: the disk
was written with no errors reported, but on testing proved to be unreadable
to linux 2.4.21. On mounting the disk a warning was reported:
Warning: defective CD-ROM. Enabling "cruft" mount option.
The large file now appeared to be only 2869191 bytes and is truncated
on reading.
Examining the Linux sources shows the following comment in fs/isofs/inode.c:
/*
* The ISO-9660 filesystem only stores 32 bits for file size.
* mkisofs handles files up to 2GB-2 = 2147483646 = 0x7FFE bytes
* in size. This is according to the large file summit paper from 1996.
* WARNING: ISO-9660 filesystems > 1 GB and even > 2 GB are fully
* legal. Do not prevent to use DVD's [EMAIL PROTECTED]
*/
if ((inode->i_size < 0 || inode->i_size > 0x7FFE) &&
inode->i_sb->u.isofs_sb.s_cruft == 'n') {
printk(KERN_WARNING "Warning: defective CD-ROM. "
"Enabling \"cruft\" mount option.\n");
inode->i_sb->u.isofs_sb.s_cruft = 'y';
}
I think this is implying that files > 2GB are legal, but can not be
handled by the Linux kernel. The comment also suggests that mkisofs
won't handle them. However it doesn't (at least for this particular
version of mkisofs) produce any warning or error when the disk is
created.
Something to beware of, since it may cause confusion or lost data.
Gary
DVDs created with too large files
I have been using dvd+rw-tools (5.13.4.7.4) and mkisofs (cdrtools 1.11a29)
to write backups to DVD. This generally works. However I encountered
a problem when one of the files was 2351679431 bytes in size: the disk
was written with no errors reported, but on testing proved to be unreadable
to linux 2.4.21. On mounting the disk a warning was reported:
Warning: defective CD-ROM. Enabling "cruft" mount option.
The large file now appeared to be only 2869191 bytes and is truncated
on reading.
Examining the Linux sources shows the following comment in fs/isofs/inode.c:
/*
* The ISO-9660 filesystem only stores 32 bits for file size.
* mkisofs handles files up to 2GB-2 = 2147483646 = 0x7FFE bytes
* in size. This is according to the large file summit paper from 1996.
* WARNING: ISO-9660 filesystems > 1 GB and even > 2 GB are fully
* legal. Do not prevent to use DVD's [EMAIL PROTECTED]
*/
if ((inode->i_size < 0 || inode->i_size > 0x7FFE) &&
inode->i_sb->u.isofs_sb.s_cruft == 'n') {
printk(KERN_WARNING "Warning: defective CD-ROM. "
"Enabling \"cruft\" mount option.\n");
inode->i_sb->u.isofs_sb.s_cruft = 'y';
}
I think this is implying that files > 2GB are legal, but can not be
handled by the Linux kernel. The comment also suggests that mkisofs
won't handle them. However it doesn't (at least for this particular
version of mkisofs) produce any warning or error when the disk is
created.
Something to beware of, since it may cause confusion or lost data.
Gary
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Cdrecord-support] Re: [Cdrecord-developers] Re: Cdrecord bug in DAO mode (version 2.01a19)
Rob Bogus wrote: [incorrect audio cd] It's not clear why using a newer version might trigger a problem, > but the firmware might have a bug in one mode or another. The firmware in some LiteOn writer produce incorrect subchannel data for audio cd. In later firmware, this bug is fixed. If cdrecord produce the subchannel data, then you get a correct audio cd: see option -raw. I'll check the firware rev and exact model when I get back to the system in ten days or so. The system is in another location. It's an ASUS 20x writer, but I will do a checkdrive and get details then. Try raw too. HTH Udo
Re: [Cdrecord-support] Re: [Cdrecord-developers] Re: Cdrecord bug in DAO mode (version 2.01a19)
Rob Bogus wrote: [incorrect audio cd] It's not clear why using a newer version might trigger a problem, > but the firmware might have a bug in one mode or another. The firmware in some LiteOn writer produce incorrect subchannel data for audio cd. In later firmware, this bug is fixed. If cdrecord produce the subchannel data, then you get a correct audio cd: see option -raw. I'll check the firware rev and exact model when I get back to the system in ten days or so. The system is in another location. It's an ASUS 20x writer, but I will do a checkdrive and get details then. Try raw too. HTH Udo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
