我的 OSX Mountain Lion 有两个用户（例如，me和otheruser）。
当以 身份登录时me，我可以查看/Users/otheruser/Public，并将文件放入/Users/otheruser/Public/Drop Box，但我看不到它们。 这对 finder 和 shell (ls "/Users/otheruser/Public/Drop Box"打印ls: .: Permission denied) 的作用相同。
但是，如果文件名称与您要放入的文件名称相同/Users/otheruser/Public/Drop Box，则情况会发生变化：
。
使用 shell：
$ cp a.txt "/Users/otheruser/Public/Drop Box"
$
复制成功，并且中的文件/Users/otheruser/Public/Drop Box被覆盖。
如果通过程序中的文件系统 API 进行复制，则该文件也会被覆盖。
是什么导致了行为上的差异？这种差异是故意的吗（即 Apple 想要这样吗）？如果不是故意的，哪种行为是正确的？
答案1
我认为 Finder 的行为是一个错误，但这种差异部分是故意的（并且是由于理念上的差异）。当您将cp一个文件复制到另一个文件之上时，它会直接替换该文件而不询问（甚至不会注意到已经发生了这种情况）。通常，Finder 会询问您是否确定要替换它；在这种情况下，文件夹权限似乎阻止它成功执行此操作，因此您会收到错误消息。
我可能应该稍微解释一下 Drop Box 文件夹的权限，以澄清这些权限实际上允许和不允许什么。文件夹有三种基本访问权限：读取、写入和“执行”（有时称为“搜索”）。读取使您能够读取文件夹中项目的名称，但实际上并不授予以任何方式触摸它们的能力。写入使您能够添加、删除和重命名文件夹中的项目。“执行”使您能够“触摸”文件夹的内容如果您知道文件名。
当您使用 Finder 授予某人对文件夹的“只读”访问权限时，它实际上授予读取和执行权限；这意味着他们可以看到其中的文件和文件夹的名称，和与他们交互（取决于项目本身的权限）。如果您实际上授予了读取权限而不授予执行权限，他们可以看到文件名，但看不到文件的其他任何内容（即，ls在这样的文件夹中可以工作，但ls -l在尝试获取文件的属性时会出现权限错误）。
如果你授予某人对某个文件夹的执行权限（而不授予其他任何权限），则意味着他们可以使用该文件夹中的文件如果他们知道（或猜测）文件名。ls /path/to/exec-folder会失败，但ls -l /path/to/exec-folder/filename会起作用如果存在该名称的文件。
Drop Box 文件夹对除所有者之外的所有人具有写入和执行权限（但没有读取权限）。这意味着在 /Users/otheruser/Public/Drop Box 中，您可以添加文件、列出其属性（如果您知道其名称），甚至可以移动、重命名或删除它们（同样，如果您知道其名称）。Finder 无法利用这一点，因为它真正想要的是查看文件夹的内容；由于它无法做到这一点，因此它放弃了与 Drop Box 的交互。许多命令行工具在执行操作时更加精确，因此甚至不会注意到它们正在不可读的文件夹中工作：
$ echo "This is the file's contents." >somefile.txt
$ cp somefile.txt /Users/otheruser/Public/Drop\ Box
$ ls /Users/otheruser/Public/Drop\ Box # Unable to look around
ls: Drop Box: Permission denied
$ ls -l /Users/otheruser/Public/Drop\ Box/somefile.txt # But if you know the filename...
-rw-r--r--+ 1 gordon staff 29 Mar 26 21:35 /Users/otheruser/Public/Drop Box/somefile.txt
$ more /Users/otheruser/Public/Drop\ Box/somefile.txt
This is the file's contents.
$ mv /Users/otheruser/Public/Drop\ Box/somefile.txt /Users/otheruser/Public/Drop\ Box/newname.txt
$ rm /Users/otheruser/Public/Drop\ Box/newname.txt
$