Joerg Schilling pointed out that RockRidge v. 1.12 extends the PX entry.
This patch stores the inode number that is now included.
He has also mentioned 'implementing support for new inode features' wrt to a
mkisofs fingerprint. Perhaps that will come at a later date.
Regardless, that can be built on this patch since now the inode number gets
stored.
This patch has been tested against mounting an ISO-9660 image in
loopback that supports RockRidge v. 1.12 (thank you to Joerg for a beta
of mkisofs that does this).
This should apply against the latest git.
---
Add support of RockRidge v. 1.12.
RockRidge v. 1.12 adds an inode number field to the PX entry, so we might as
well store it too.
Signed-off-by: James Lamanna <[email protected]>
---
diff --git a/fs/isofs/rock.c b/fs/isofs/rock.c
index f3a1db3..241d8b6 100644
--- a/fs/isofs/rock.c
+++ b/fs/isofs/rock.c
@@ -4,6 +4,9 @@
* (C) 1992, 1993 Eric Youngdale
*
* Rock Ridge Extensions to iso9660
+ *
+ * James Lamanna : Support v. 1.12 PX Entry
+ * ([email protected]) : 17th Oct 2006
*/
#include <linux/slab.h>
@@ -148,8 +151,14 @@ static int rock_check_overflow(struct ro
len = sizeof(struct RR_RR_s);
break;
case SIG('P', 'X'):
- len = sizeof(struct RR_PX_s);
+ {
+ struct rock_ridge *rr = (struct rock_ridge *)rs->chr;
+ if (rr->len == PX_112_LEN)
+ len = sizeof(struct RR_PX_112_s);
+ else
+ len = sizeof(struct RR_PX_s);
break;
+ }
case SIG('P', 'N'):
len = sizeof(struct RR_PN_s);
break;
@@ -349,6 +358,9 @@ #endif
inode->i_nlink = isonum_733(rr->u.PX.n_links);
inode->i_uid = isonum_733(rr->u.PX.uid);
inode->i_gid = isonum_733(rr->u.PX.gid);
+
+ if (rr->len == PX_112_LEN)
+ inode->i_ino = isonum_733(rr->u.PX_112.ino);
break;
case SIG('P', 'N'):
{
diff --git a/fs/isofs/rock.h b/fs/isofs/rock.h
index ed09e2b..4b5c721 100644
--- a/fs/isofs/rock.h
+++ b/fs/isofs/rock.h
@@ -35,6 +35,16 @@ struct RR_PX_s {
char gid[8];
};
+/* RR 1.12 extends the PX entry with a POSIX File Serial Number */
+#define PX_112_LEN (sizeof(struct RR_PX_112_s) + offsetof(struct rock_ridge, u))
+struct RR_PX_112_s {
+ char mode[8];
+ char n_links[8];
+ char uid[8];
+ char gid[8];
+ char ino[8];
+};
+
struct RR_PN_s {
char dev_high[8];
char dev_low[8];
@@ -102,6 +112,7 @@ struct rock_ridge {
struct SU_ER_s ER;
struct RR_RR_s RR;
struct RR_PX_s PX;
+ struct RR_PX_112_s PX_112;
struct RR_PN_s PN;
struct RR_SL_s SL;
struct RR_NM_s NM;
James Lamanna <[email protected]> wrote:
>
> Joerg Schilling pointed out that RockRidge v. 1.12 extends the PX entry.
> This patch stores the inode number that is now included.
> He has also mentioned 'implementing support for new inode features' wrt to a
> mkisofs fingerprint. Perhaps that will come at a later date.
> Regardless, that can be built on this patch since now the inode number gets
> stored.
>
> This patch has been tested against mounting an ISO-9660 image in
> loopback that supports RockRidge v. 1.12 (thank you to Joerg for a beta
> of mkisofs that does this).
> This should apply against the latest git.
If you did not test this as NFS server, you may have introduced a problem....
J?rg
--
EMail:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
James Lamanna <[email protected]> wrote:
>
> Joerg Schilling pointed out that RockRidge v. 1.12 extends the PX entry.
> This patch stores the inode number that is now included.
> He has also mentioned 'implementing support for new inode features' wrt to a
> mkisofs fingerprint. Perhaps that will come at a later date.
> Regardless, that can be built on this patch since now the inode number gets
> stored.
>
> This patch has been tested against mounting an ISO-9660 image in
> loopback that supports RockRidge v. 1.12 (thank you to Joerg for a beta
> of mkisofs that does this).
> This should apply against the latest git.
Let me add some more notes:
The linux NFS server interface is unnecessarily complex and will make it
a lot harder than a "single line change" to make the filesystem correct in case
Linux likes to benefit from the inode numbers in RRip 1.12 to support correct
hardlinks.
If you believe that you understand the NFS server issues, you should fix the
code so that NFS exports will work correctly after the change. If you don't know
what's going on there, you may need to spend a few days with testing and
debugging.
Note that you need to be able to "re-open" any file from a NFS file handle only...
There are many constraints that need to be redeemed and the new algorithm needs
to work correctly with old and with new media.
And finally a note to Alan Cox:
Instead of being unwilling to follow the Nettiquette by removing people from the
To: list with your replies and instead of sending useless replies that don't help
people, you should better stay quiet.
J?rg
--
EMail:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Ar Iau, 2006-10-19 am 11:48 +0200, ysgrifennodd Joerg Schilling:
> Instead of being unwilling to follow the Nettiquette by removing people from the
> To: list with your replies and instead of sending useless replies that don't help
> people, you should better stay quiet.
Perhaps I felt it appropriate that my comment went to the list. You may
not like it but thats your problem not mine. I'm glad you spend all your
time lauding Solaris, I can't think of a person I'd most rather have as
lobbyist for a rival OS.
Alan
On 10/19/06, Joerg Schilling <[email protected]> wrote:
> James Lamanna <[email protected]> wrote:
>
> >
> > Joerg Schilling pointed out that RockRidge v. 1.12 extends the PX entry.
> > This patch stores the inode number that is now included.
> > He has also mentioned 'implementing support for new inode features' wrt to a
> > mkisofs fingerprint. Perhaps that will come at a later date.
> > Regardless, that can be built on this patch since now the inode number gets
> > stored.
> >
> > This patch has been tested against mounting an ISO-9660 image in
> > loopback that supports RockRidge v. 1.12 (thank you to Joerg for a beta
> > of mkisofs that does this).
> > This should apply against the latest git.
>
> Let me add some more notes:
>
> The linux NFS server interface is unnecessarily complex and will make it
> a lot harder than a "single line change" to make the filesystem correct in case
> Linux likes to benefit from the inode numbers in RRip 1.12 to support correct
> hardlinks.
>
> If you believe that you understand the NFS server issues, you should fix the
> code so that NFS exports will work correctly after the change. If you don't know
> what's going on there, you may need to spend a few days with testing and
> debugging.
>
> Note that you need to be able to "re-open" any file from a NFS file handle only...
> There are many constraints that need to be redeemed and the new algorithm needs
> to work correctly with old and with new media.
Hopefully I will have some time to test this box as a NFS server soon.
Unfortunately, hacking on Linux is not exactly my full-time job at the
moment.
Anyways, the patch should probably be put on hold until these
potential issues are addressed. Everything should still function fine
without any RR 1.12 patch.
-- James