网络文件系统协议( 七 )


void;
};
"attrstat"结构是一个公共的过程结果 。它包含着一个"status",假如这个调用成功,它将也包含操作作用于那个文件的属性 。
2.3.10.diropargs(目录操作参数)
structdiropargs{
fhandledir;
filenamename;
};
"diropargs"结构使用在目录属性操作中 。"dir"是在其中寻找文件"name"的那个目录 。一个目录操作影响这个目录 。
2.3.11.diropres(目录操作结果)
uniondiropresswitch(statstatus){
caseNFS_OK:
struct{
fhandlefile;
fattrattributes;
}diropok;
default:
void;
};
在"diropres"中返回目录操作的结果 。假如这个调用成功,与这个文件相关的新文件句柄"file"和文件属性"attributes"将连同"status"一起返回 。
3.NFS实现中的问题
NFS协议设计为答应不同的操作系统共享文件 。但是,因为它在UNIX环境中设计,所以,许多操作与UNIX文件系统的操作语义相似 。这一节讨论实现中非凡的细节和语义的问题 。
3.1服务器/客户端的关系
NFS协议被设计为让服务器尽可能的简单和通用 。有时候假如客户端想实现复杂的文件系统语义,服务器的简单性可能是一个难题 。
例如,一些操作系统答应删除打开的文件 。一个进程能够打开文件,当文件打开的时候,从目录中删除它 。只要进程保持文件打开,这个文件就可以被读写,即使这个文件在文件系统中没有名字 。对于无状态服务器来说,实现这些语义是不可能的 。客户端可以使用一些技巧,诸如在删除时重命名这个文件,只在它关闭的时候删除它 。我们相信服务器提供了足够的功能在客户端上实现大多数文件系统的语义 。
每一个NFS客户端也是一个潜在的服务器,远程和本地安装的文件系统可以自由的混合在一起 。当客户端浏览远程文件系统的目录树,到达在服务器上另一个远程系统的安装点的时候,将会出现一些有趣的问题 。要答应服务器跟随第二个远程安装就需要循环检测,服务器查找和用户重新生效 。代替的做法是,我们决定不让客户端越过服务器的安装点 。.当客户端在一个服务器已经安装了文件系统的目录中查询的时候,客户端将看见下面的目录而不是安装的目录 。
例如,假如服务器有一个叫做"/usr"的文件系统,把另一个文件系统安装在"/usr/src"上,假如客户端安装了"/usr",它将看不到"/usr/src"的安装版本 。客户端能做远程安装以配合服务器的安装点保持服务器的视图 。在这个例子中,客户端应该除了安装"/usr"之外,还要安装"/usr/src",即使它们是来自同一台服务器 。
3.2路径名解析
路径名总是在客户端解析的规则有点复杂 。例如,符号链接在不同的客户端可以有不同的解释 。对于非UNIX实现的另一个共同的问题就是路径".."的专门的解释是给定的目录的父目录 。此协议的下一个修订版将使用一个明确的标志指示父目录 。
3.3许可问题
严格的讲,NFS协议没有定义服务器使用的许可权限检查 。但是,也希望使用AUTH_UNIX类型认证这一基础的保护机制作正常的操作系统许可权限检查,服务器得到客户的有效"uid",有效"gid"和每次调用上的组,使用它们来检查许可 。使用这种方法产生的问题可以用一些有趣的途径来解决 。
使用"uid"和"gid"暗示着客户端和服务器分享相同的"uid"列表 。每一对服务器和客户端必须有相同的用户到"uid",组到"gid"的映射 。因为每一个客户端也可能是一台服务器,这意味着整个网络共享相同的"uid/gid"空间 。AUTH_DES(和NFS协议的下一个修订版)使用字符串来代替数字,但是仍有复杂的问题要解决 。

推荐阅读