From: James Lamanna <jlamanna@gmail.com>
To: linux-kernel@vger.kernel.org,
Joerg.Schilling@fokus.fraunhofer.de, ismail@pardus.org.tr
Subject: Re: Linux ISO-9660 Rock Ridge bug needs fix
Date: Tue, 17 Oct 2006 14:07:24 -0700 (PDT) [thread overview]
Message-ID: <4535460c.5a4933ac.778b.ffffc157@mx.google.com> (raw)
In-Reply-To: <453521a4.QReHSjx3qh9sf0jr%Joerg.Schilling@fokus.fraunhofer.de>
Joerg Shilling wrote:
> Ismail Donmez <ismail@pardus.org.tr> wrote:
>
> > > Well, this is why I did offer a preliminary version of thelatest mkisofs
> > > sources.....
> >
> > Well a simple mkisofs some_file > test.iso and mounting that on a loop
> > device
> > worked fine.
> >
> >
> > > But note: your patch does not fix the original implementation bug and it
> > > is
> > > most unlikely that the hack will do the right things in all cases.
> >
> > Well I don't know whats the original implementation bug and rock.c seems to
> > be
> > pretty much old with no active maintainer.
>
> Please read again my original mail....
> 1) you need to create images with Rock Ridge
>
> 2) a correct implementation is prepared to deal with more recent versions
> without a need for new changes.
>
> So, if the implementation does not deal with the new version _without_
> explicitely knowing about v1.12 it is still broken.
Hi Joerg,
I am unable to duplicate this bug that supposedly exists even on older
kernels.
For instance, on a 2.6.16 kernel I do the following:
$ mkisofs -R -v -o rrtest.iso testiso
mkisofs 2.01.01a18 (i686-pc-linux-gnu)
Scanning testiso
Scanning testiso/d3
Scanning testiso/f2
Writing: Initial Padblock Start Block 0
Done with: Initial Padblock Block(s) 16
Writing: Primary Volume Descriptor Start Block 16
Done with: Primary Volume Descriptor Block(s) 1
Writing: End Volume Descriptor Start Block 17
Done with: End Volume Descriptor Block(s) 1
Writing: Version block Start Block 18
Done with: Version block Block(s) 1
Writing: Path table Start Block 19
Done with: Path table Block(s) 4
Writing: Directory tree Start Block 23
Done with: Directory tree Block(s) 3
Writing: Directory tree cleanup Start Block 26
Done with: Directory tree cleanup Block(s) 0
Writing: Extension record Start Block 26
Done with: Extension record Block(s) 1
Writing: The File(s) Start Block 27
Total translation table size: 0
Total rockridge attributes bytes: 1163
Total directory bytes: 4096
Path table size(bytes): 30
Done with: The File(s) Block(s) 2752
Writing: Ending Padblock Start Block 2779
Done with: Ending Padblock Block(s) 150
Max brk space used 21000
2929 extents written (5 MB)
$ mount rrtest.iso testmount -t iso9660 -o loop=/dev/loop0
Examining testmount/ I find everything there that should be there.
dmesg even reports:
ISO 9660 Extensions: RRIP_1991A
So it is indeed using RockRidge of some sort.
(If there is something I'm doing wrong here, please point it out so I can find
this bug).
I do agree that any implementation should not need to know about the new
version in order to function in 1.10 mode. However, in order to support the
new fields, in this case assigning inode->i_ino from the new PX entry field, it
must know that the record is a v. 1.12 one.
Thanks.
-- James
next prev parent reply other threads:[~2006-10-17 21:07 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-17 14:45 Linux ISO-9660 Rock Ridge bug needs fix Joerg Schilling
2006-10-17 17:41 ` Ismail Donmez
2006-10-17 18:02 ` Luca Tettamanti
2006-10-17 18:14 ` Ismail Donmez
2006-10-17 18:16 ` Joerg Schilling
2006-10-17 18:32 ` Ismail Donmez
2006-10-17 19:50 ` Luca Tettamanti
2006-10-17 19:38 ` Pekka Enberg
2006-10-19 21:31 ` H. Peter Anvin
2006-10-17 18:12 ` Joerg Schilling
2006-10-17 18:28 ` Ismail Donmez
2006-10-17 18:32 ` Joerg Schilling
2006-10-17 18:39 ` Ismail Donmez
2006-10-17 21:07 ` James Lamanna [this message]
2006-10-17 21:32 ` Joerg Schilling
2006-10-17 21:51 ` James Lamanna
2006-10-17 22:24 ` Joerg Schilling
2006-10-17 23:06 ` Alan Cox
2006-10-18 15:07 ` Joerg Schilling
2006-10-17 19:53 ` Jan Engelhardt
2006-10-17 18:37 ` James Lamanna
[not found] <771eN-VK-9@gated-at.bofh.it>
[not found] ` <771yn-1XU-65@gated-at.bofh.it>
2006-10-17 23:09 ` Bodo Eggert
2006-10-18 15:14 ` Joerg Schilling
2006-10-18 22:45 ` Bodo Eggert
2006-10-18 23:29 ` Joerg Schilling
2006-10-19 21:16 ` Bodo Eggert
2006-10-19 21:39 ` Joerg Schilling
2006-10-19 21:49 ` Alan Cox
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4535460c.5a4933ac.778b.ffffc157@mx.google.com \
--to=jlamanna@gmail.com \
--cc=Joerg.Schilling@fokus.fraunhofer.de \
--cc=ismail@pardus.org.tr \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox