[SOLVED] Re: strangeness when writing iso9660/hfs hybrid disks
Hi, On Mon, Jun 23, 2003 at 03:44:35PM +0200, Joerg Schilling wrote: > mkisofs has passed the compliance test for Picture CDs from Kodak. > > If you have problems without using HFS, they are definitely a result > of a Linux bug. the corruption does not happen without using HFS unless I also use -apple. It only happens if I tell mkisofs to look for Apple resource forks. I have found the cause of the corruption. It is indeed a Linux bug, or perhaps more accurately a bug in the Linux mount(8) manpage. If I use the "unhide" mount option in /etc/fstab, Linux will pick up the resource forks (probably because they have the same filenames as the corresponding data forks) instead of the data forks, causing the corruption. The corruption stopped occuring after I removed the "unhide" option from my /etc/fstab. I originally added the "unhide" option in an attempt to also show the resource forks when I mount the CD under Linux; obviously that doesn't work. I wonder if it is technically possible for mkisofs to somehow write the iso image in a way that can prevent this from happening, even though it is obvious now that it's the user's (i.e., my) fault. Thanks very much for the answers, -- Ambrose LI Cheuk-Wing <[EMAIL PROTECTED]> http://ada.dhs.org/~acli/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [SOLVED] Re: strangeness when writing iso9660/hfs hybrid disks
>From [EMAIL PROTECTED] Mon Jun 23 18:16:17 2003 >On Mon, Jun 23, 2003 at 03:44:35PM +0200, Joerg Schilling wrote: >> mkisofs has passed the compliance test for Picture CDs from Kodak. >> >> If you have problems without using HFS, they are definitely a result >> of a Linux bug. >the corruption does not happen without using HFS unless I also use >-apple. It only happens if I tell mkisofs to look for Apple resource >forks. This is how Kodak Poto/picture CDs are written. >I have found the cause of the corruption. It is indeed a Linux bug, >or perhaps more accurately a bug in the Linux mount(8) manpage. >If I use the "unhide" mount option in /etc/fstab, Linux will pick up >the resource forks (probably because they have the same filenames as >the corresponding data forks) instead of the data forks, causing >the corruption. The corruption stopped occuring after I removed the >"unhide" option from my /etc/fstab. Well, the resource fork must be the file _before_ the data (content) of the file. The name is the same.. Jörg EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) If you don't have iso-8859-1 [EMAIL PROTECTED](work) chars I am J"org Schilling URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [SOLVED] Re: strangeness when writing iso9660/hfs hybrid disks
[EMAIL PROTECTED] (Ambrose Li) quoted and then wrote: >If I use the "unhide" mount option in /etc/fstab, Linux will pick up >the resource forks (probably because they have the same filenames as >the corresponding data forks) instead of the data forks, causing >the corruption. The corruption stopped occuring after I removed the >"unhide" option from my /etc/fstab. > >I originally added the "unhide" option in an attempt to also show >the resource forks when I mount the CD under Linux; obviously that >doesn't work. > >I wonder if it is technically possible for mkisofs to somehow write >the iso image in a way that can prevent this from happening, even >though it is obvious now that it's the user's (i.e., my) fault. As someone who does not use Linux, I would say it is not the user's fault. When that bit is set, it means the first extent is Macintosh resource fork data. That bit was put into the standard specifically for that purpose. Linux should make it _extremely_ difficult to handle an extent flagged in that fashion as anything but a resource fork (and Linux likely has no use for a resource fork except when serving files to Macintoshes). If there _were_ some change that mkisofs could make to the disc image to trick Linux into behaving differently it would be just a trick and not based on the ISO9660 standard. Thus it might fail to work on some other version of Linux. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [SOLVED] Re: strangeness when writing iso9660/hfs hybrid disks
[EMAIL PROTECTED] wrote: As someone who does not use Linux, I would say it is not the user's fault. When that bit is set, it means the first extent is Macintosh resource fork data. That bit was put into the standard specifically for that purpose. Linux should make it _extremely_ difficult to handle an extent flagged in that fashion as anything but a resource fork (and Linux likely has no use for a resource fork except when serving files to Macintoshes). The user deliberately selected an option to make those forks visible. Linux doesn't (deliberately) make things dificult, it just makes the default safe in most cases, and allows you to make a choice. If you ask to see the fork you can't complain that the fork is visible. -- E. Robert Bogusta It seemed like a good idea at the time -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [SOLVED] Re: strangeness when writing iso9660/hfs hybrid disks
On Fri, Jun 27, 2003 at 11:40:59PM -0400, Rob Bogus wrote: > The user deliberately selected an option to make those forks > visible. Linux doesn't (deliberately) make things dificult, > it just makes the default safe in most cases, and allows > you to make a choice. If you ask to see the fork you can't > complain that the fork is visible. Yes, that's why I say it is my fault but also a bug in the Linux docs. As someone who does not know all the details of the ISO9660 standard, one would never have thought that the resource fork and the data fork would have the same name and therefore the resource fork would make the data fork invisible. Certainly the user (myself) made a stupid choice, and the choice is made because the documentation did not make it clear that the option is unsafe. In fact, I did read all of the mount and mkisofs man pages, and still made this stupid choice, perhaps it is not unreasonable to say that the docs *are* unclear. I did submit a bug report; the man page should mention this in the future... Best regards, -- Ambrose LI Cheuk-Wing <[EMAIL PROTECTED]> http://ada.dhs.org/~acli/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [SOLVED] Re: strangeness when writing iso9660/hfs hybrid disks
[EMAIL PROTECTED] (Ambrose Li) quoted and then wrote: >On Fri, Jun 27, 2003 at 11:40:59PM -0400, Rob Bogus wrote: > >> The user deliberately selected an option to make those forks >> visible. Linux doesn't (deliberately) make things dificult, >> it just makes the default safe in most cases, and allows >> you to make a choice. If you ask to see the fork you can't >> complain that the fork is visible. > >Yes, that's why I say it is my fault but also a bug in the Linux >docs. As someone who does not know all the details of the >ISO9660 standard, one would never have thought that the resource >fork and the data fork would have the same name and therefore >the resource fork would make the data fork invisible. Certainly >the user (myself) made a stupid choice, and the choice is made >because the documentation did not make it clear that the option >is unsafe. In fact, I did read all of the mount and mkisofs man >pages, and still made this stupid choice, perhaps it is not >unreasonable to say that the docs *are* unclear. > >I did submit a bug report; the man page should mention this in >the future... The ISO 9660 bit specifies that the very first extent is the resource fork. The Linux option makes that first extent separately visible. What effect does not Linux option have on the _other_ extents that also have the same name ? One must use multiple extents to have an ISO 9660 file larger than a certain size, or one that spans volumes. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [SOLVED] Re: strangeness when writing iso9660/hfs hybrid disks
>From: Rob Bogus <[EMAIL PROTECTED]> >>As someone who does not use Linux, I would say it is not the user's >>fault. When that bit is set, it means the first extent is Macintosh >>resource fork data. That bit was put into the standard specifically >>for that purpose. Linux should make it _extremely_ difficult to >>handle an extent flagged in that fashion as anything but a resource >>fork (and Linux likely has no use for a resource fork except when >>serving files to Macintoshes). >> >> >The user deliberately selected an option to make those forks visible. >Linux doesn't (deliberately) make things dificult, it just makes the >default safe in most cases, and allows you to make a choice. If you ask >to see the fork you can't complain that the fork is visible. Solaris does support extended attributes and could be made able to make the files visible in a decent way ;-) Jörg EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) If you don't have iso-8859-1 [EMAIL PROTECTED](work) chars I am J"org Schilling URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [SOLVED] Re: strangeness when writing iso9660/hfs hybrid disks
>From: [EMAIL PROTECTED] >>is unsafe. In fact, I did read all of the mount and mkisofs man >>pages, and still made this stupid choice, perhaps it is not >>unreasonable to say that the docs *are* unclear. >> >>I did submit a bug report; the man page should mention this in >>the future... Not a thing that the mkisofs man page should mention, is it just not related to mkisofs. If ever, it is related to the way Apple implemented it (so look at Apple documentations). >The ISO 9660 bit specifies that the very first extent is the >resource fork. The Linux option makes that first extent separately >visible. What effect does not Linux option have on the _other_ >extents that also have the same name ? One must use multiple >extents to have an ISO 9660 file larger than a certain size, or >one that spans volumes. Wrong: Resource forks are not multi-extent files but associated files. They are fully documented in ISO-9660. The standard even makes clear that both files have the same name. Jörg EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) If you don't have iso-8859-1 [EMAIL PROTECTED](work) chars I am J"org Schilling URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [SOLVED] Re: strangeness when writing iso9660/hfs hybrid disks
Hi, On Mon, Jun 30, 2003 at 02:52:50PM +0200, Joerg Schilling wrote: > >>I did submit a bug report; the man page should mention this > >>in the future... > > Not a thing that the mkisofs man page should mention, is it > just not related to mkisofs. If ever, it is related to the way > Apple implemented it (so look at Apple documentations). sorry for not being clear enough. I did submit a bug report for the Linux mount(8) man page. I believe it is more of a bug on the Linux side, though some extra notes on the mkisofs side would certainly be nice for clueless users (like me). Best regards, -- Ambrose LI Cheuk-Wing <[EMAIL PROTECTED]> http://ada.dhs.org/~acli/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [SOLVED] Re: strangeness when writing iso9660/hfs hybrid disks
[EMAIL PROTECTED] (Joerg Schilling) quoted and then wrote: >>From: [EMAIL PROTECTED] >>The ISO 9660 bit specifies that the very first extent is the >>resource fork. The Linux option makes that first extent separately >>visible. What effect does not Linux option have on the _other_ >>extents that also have the same name ? One must use multiple >>extents to have an ISO 9660 file larger than a certain size, or >>one that spans volumes. > >Wrong: Resource forks are not multi-extent files but associated files. >They are fully documented in ISO-9660. The standard even makes clear >that both files have the same name. The implementation of associated files is exactly that of subsequent extents (aside from ordering). My question was intended to read "What effect does that Linux option" have, with regard to handling multiple extents. Is there similar confusion, or is that part better documented. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [SOLVED] Re: strangeness when writing iso9660/hfs hybrid disks
On Tue, Jul 01, 2003 at 06:46:50AM -0400, [EMAIL PROTECTED] wrote: > The implementation of associated files is exactly that of > subsequent extents (aside from ordering). My question was > intended to read "What effect does that Linux option" have, > with regard to handling multiple extents. Is there similar > confusion, or is that part better documented. >From a user's viewpoint, no, it is as poorly documented. The user documentation for the "unhide" option, in its entirety, is as follows: unhide Also show hidden and associated files. There may be some docs in the kernel source, but I think for the user, having to look there is a bit too much. -- Ambrose LI Cheuk-Wing <[EMAIL PROTECTED]> http://ada.dhs.org/~acli/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [SOLVED] Re: strangeness when writing iso9660/hfs hybrid disks
Joerg Schilling wrote: From: Rob Bogus <[EMAIL PROTECTED]> As someone who does not use Linux, I would say it is not the user's fault. When that bit is set, it means the first extent is Macintosh resource fork data. That bit was put into the standard specifically for that purpose. Linux should make it _extremely_ difficult to handle an extent flagged in that fashion as anything but a resource fork (and Linux likely has no use for a resource fork except when serving files to Macintoshes). The user deliberately selected an option to make those forks visible. Linux doesn't (deliberately) make things dificult, it just makes the default safe in most cases, and allows you to make a choice. If you ask to see the fork you can't complain that the fork is visible. Solaris does support extended attributes and could be made able to make the files visible in a decent way ;-) I have no Mac to try, I do have some Solaris machines, although I normally just use them as servers. Does this mean that Solaris could be a a fileserver for Macs? Or just that Solaris would let you see and/or use the forks in a useful way? In any case, my point was that if you ask for something unpleasant to happen, it's not the o/s fault. Implementing "rm -r /" is not a Linux "bug," or Solaris or AIX or whatever. Distributed intelligence means above and below the keyboard. -- E. Robert Bogusta It seemed like a good idea at the time
