Sophie: coda-doc-5.2.0-4mdk noarch

coda-doc-5.2.0-4mdk.noarch.rpm

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
 <META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.9">
 <TITLE> The Venus kernel interface: Inode numbers </TITLE>
 <LINK HREF="kernel-venus-protocol-6.html" REL=previous>
 <LINK HREF="kernel-venus-protocol.html#toc7" REL=contents>
</HEAD>
<BODY>
Next
<A HREF="kernel-venus-protocol-6.html">Previous</A>
<A HREF="kernel-venus-protocol.html#toc7">Contents</A>
<HR>
<H2><A NAME="s7">7. Inode numbers </A></H2>

<P>
<P>The Unix stat system call returns inode numbers for files.  These
should be correct for Coda files for library calls like getwd and tar
to function correctly.
<P>The mount points of volumes complicate the values which Venus assigns to the inode numbers in the statbuf structure.  The rules are as follows:
<P>
<OL>
<LI> A fid is converted to an integer (vol&lt;&lt;20) + (vnode&lt;&lt;10) + (uniq).</LI>
<LI> If a fid is the root of a volume, then it is assigned the inode number of the symlink which is its mountpoint. </LI>
</OL>
<P>The kernel should never cache the symlink mountpoints but may see them
in case they cannot be covered. Also downcalls are made to purge the
symlink fid from the cache, despite the fact that the kernel has never
seen the mountpoint fid before.
<P>Kernel code for Coda will need to implement a lookup mechanism to find
vnodes (BSD) inodes (Linux) or FileHandles (Win) based on Fid, and it
will need to be careful to get things right for volume roots.
<P>
<HR>
Next
<A HREF="kernel-venus-protocol-6.html">Previous</A>
<A HREF="kernel-venus-protocol.html#toc7">Contents</A>
</BODY>
</HTML>