Messages in this thread |  | | Date | Mon, 28 Aug 2000 11:27:37 -0600 | From | "Jeff V. Merkey" <> | Subject | Re: NWFS rename() problem |
| |
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/
|  |