Alexander Viro wrote:
>
Al, Andi, and the other folks who responded,
I held off responding because after seeing the issues folks raised on
Thursday last week, and I was hit with an epiphany between the eyes like
a bolt of lightening. The inode model and the NetWare model are
completely incongruent with each other -- not surprising.
Here's what's up here:
NetWare organizes every 4K directory block as being owned by a
particular parent, and all entries contained in these blocks must always
belong to the same parent. When a file gets renamed under NetWare, new
directory entries will always get created in the new parent directory,
which is always guanrateed to be in another 4K block of the directory
file. The Directory file is a linear collection of 128 byte records,
however, every 4K boundry (of 32 individual 128 byte records) is assumed
to be assigned to a particular parent, or be free space.
The Linux inode model keeps inode numbers consistent for a file, even
if it's been moved to another directory. Since I've been using the
directory record number in the master directory file as the inode number
(since they are unique), this clearly will not work at all on Linux for
mv'ing stuff.
I have to give this more thought on the best manner to implement this.
There is not an ->i_ino field in the NFS namespace for NetWare. I setup
the NFS server on Native NetWare to see how Native NetWare is handling
this, and NetWare is returning the directory record number as the inode
number to remote clients (which is clearly wrong) -- the same method I
am using. This means that the Native NetWare NFS server is also busted
and will not preserve inode numbers across mounts. Their NFS server
however, does alias the origianl number, so mv'd files retain the same
inode number, but not accross power down or dismount/remount operations.
I know what's up now with both Native NetWare and NWFS with this, and am
working on a fix.
:-)
Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Aug 31 2000 - 21:00:21 EST