> Steve Lord <lord@xxxxxxx> wrote:
>
> > OK, here is a patch which might start to narrow down where the inode number
> > is getting lost. I seem to remember there being issues with printing 64
> > bit numbers on the ppc, so you may have to mess with this somewhat to get
> > it to function there.
>
> ok - did it (btw. the 64bit problem seems to be only happening with
> printing in hex which can be easily worked around by shifts and
> printing two longs - %Ld looks like being working)
>
> inum set to 132 from ir_startino of 128
> xfs_dialloc returned inum 132
> xfs_dir2_createname: inum = 132
>
> this is the output of your patch for my typical test: "cp XFS test"
>
> just tell me what else you are interested in ...
>
Which says that the problem is in getting the inode number into the directory
entry itself, not in creating the inode number. Hmmm,
try this patch, we are taking an 8 byte inode number and placing it in a
4 byte field, I think on a big endian machine we are copying the wrong half
of the word over.
Steve
===========================================================================
Index: linux/fs/xfs/xfs_arch.h
===========================================================================
--- /usr/tmp/TmpDir.19679-0/linux/fs/xfs/xfs_arch.h_1.27 Tue Aug 29
15:28:27 2000
+++ linux/fs/xfs/xfs_arch.h Tue Aug 29 15:23:21 2000
@@ -226,7 +226,7 @@
}
#define DIRINO4_COPY_ARCH(from,to,arch) \
if ((arch) == ARCH_NOCONVERT) { \
- bcopy(from,to,sizeof(xfs_dir2_ino4_t)); \
+ bcopy((((__u8*)from+4)),to,sizeof(xfs_dir2_ino4_t)); \
} else { \
INT_SWAP_UNALIGNED_32(from,to); \
}
|