[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]
