Oh, fair enough. I made the directory write-only. My bad. So, here's the actual behavior:
* Cannot create files in a read-only directory. * Can modify files (as in, file metadata s.a. ownership) in the read-only directory. * Can mount volumes in the read-only directory (as well as unmount). * Can list the read-only directory. * Can't remove files from read-only directory. Surprisingly, the explanation is still the same: the list of child i-nodes in the directory is stored in the i-node allocated to the directory. Some operations that touch that list end up being prevented for the wrong reason, other's that don't touch it, s.a. mounting, changing attributes, probably extended attributes to or SELinux / AppArmor policies would also be unaffected by directory being read-only. In other words, this isn't a deliberate design decision. It just happened to be this way because it was easy to do it like this. And the argument about keeping the existing functionality because it's easy is still the same. -- https://mail.python.org/mailman3//lists/python-list.python.org
