I posted this earlier, but it was right at the time that linux-fsdevel got swamped with a linux-kernel discussion, so I don't think anyone saw it. I have discovered, looking at Linux 2.4.2, that the read-only status of a mount is considered in some places to be a matter of file permissions, and in others as something separate from file permissions. So in some cases, it is the responsibility of a filesystem object's ->permission routine to check the MS_RDONLY superblock flag and deny write permission, but in other cases FS code checks MS_RDONLY itself. This seems to me inconsistent to the point of surely causing mistakes. Is there a consistent philosophy here that I'm missing? I noticed the problem when my filesystem driver had the following quirky behavior: I have an easy ->permission that grants write access in spite of the MS_RDONLY flag. When I open(O_RDWR | O_CREAT) a new file on a read-only mount, the open() fails, but the file gets created anyway. open_namei() defers to the filesystem driver for the creation part, but fails the open on its own authority later on. - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED]
