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 specifi
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
[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 th
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 implem
>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 th
>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 _extre
[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 a
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
[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
ha
[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 st
>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
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
12 matches
Mail list logo