为什么rename()系统调用禁止将无法写入的目录移动到其他目录?

我试图理解为什么这个设计决策是用4.2bsd中的rename()syscall做出的。我在这里没有试图解决的问题,只是理解行为本身的基本原理。

4.2bsd引入了rename()syscall,以允许文件的原子重命名/移动。从4.3bsd-reno/src/sys/ufs/ufs_vnops.c:

 /*
  * If ".." must be changed (ie the directory gets a new
  * parent) then the source directory must not be in the
  * directory heirarchy above the target, as this would
  * orphan everything below the source directory. Also
  * the user must have write permission in the source so
  * as to be able to change "..". We must repeat the call 
  * to namei, as the parent directory is unlocked by the
  * call to checkpath().
  */

 if (oldparent != dp->i_number)
  newparent = dp->i_number;
 if (doingdirectory && newparent) {
  VOP_LOCK(fndp->ni_vp);
  error = ufs_access(fndp->ni_vp, VWRITE, tndp->ni_cred);
  VOP_UNLOCK(fndp->ni_vp);

很明显这张支票是故意加上去的。我的问题是-为什么?这种行为应该是直觉的吗?

这样做的结果是,一个人不能移动一个目录(位于一个可以写入的目录中),也不能将该目录写入另一个可以原子地写入的目录。但是,您可以创建一个新目录,将链接移到另一个目录(假设一个目录具有读访问权限),然后删除该目录上的写位。你只是不能原子性地这么做。

% cd /tmp
% mkdir stackoverflow-question
% cd stackoverflow-question
% mkdir directory-1
% mkdir directory-2
% mkdir directory-1/directory-i-cant-write
% echo "foo" > directory-1/directory-i-cant-write/contents
% chmod 000 directory-1/directory-i-cant-write/contents
% chmod 000 directory-1/directory-i-cant-write
% mv directory-1/directory-i-cant-write directory-2
mv: rename directory-1/directory-i-cant-write to directory-2/directory-i-cant-write: Permission denied

我们现在有一个目录,我不能写的内容,我不能读,我不能移动原子。但是,通过更改权限、创建新目录、使用ln创建新链接和更改权限,我可以非原子地实现相同的效果。(作为练习留给读者)

. 并且…已经有特殊的大小写了,所以我并不特别相信,如果我不能写一个目录,我就不能“改变…”这是很直观的,这就是源代码所建议的。这除了是代码作者认为正确的行为之外,还有什么原因吗?如果我们让人们原子化地在他们可以写的目录之间移动目录(他们不能写),会有什么不好的事情发生吗?