On Thu, 19 Aug 2021, J. Bruce Fields wrote: > On Fri, Aug 13, 2021 at 05:49:19PM -0700, Andy Lutomirski wrote: > > I’ll bite. How about we attack this in the opposite direction: remove > > the deny write mechanism entirely. > > For what it's worth, Windows has open flags that allow denying read or > write opens. They also made their way into the NFSv4 protocol, but > knfsd enforces them only against other NFSv4 clients. Last I checked, > Samba attempted to emulate them using flock (and there's a comment to > that effect on the flock syscall in fs/locks.c). I don't know what Wine > does. > > Pavel Shilovsky posted flags adding O_DENY* flags years ago: > > https://lwn.net/Articles/581005/ > > I keep thinking I should look back at those some day but will probably > never get to it. O_DENYREAD is an insane flag. If a process reads a file that some other process is working on, then the only which could be hurt is the reader. So allowing a process to ask for the open to fail if someone is writing might make sense. Insisting that all opens fail does not. Any code wanting O_DENYREAD *should* use advisory locking, and any code wanting to know about read denial should too. O_DENYWRITE can make sense. When combined with a O_RDONLY open it is effectively what happens when you exec a program. You can no longer open that file for write - you get ETXTBSY. It would be nice to be able to combine O_DENYWRITE with O_RDWR. This combination is exactly what the kernel *should* do for swap files. Unfortunately it doesn't. The "i_writecount" field that is used to trigger ETXTBSY for executables doesn't work for the single-writer model. I'm not sure about O_DENYDELETE. It is a lock on the name. Unix has traditionally used lock-files to lock a name. The functionality makes sense for processes with write-access to the directory... NeilBrown
