Pip Cet: > I've taken the code from fuse/dir.c and modified it slightly to provide a > pretty minimal workaround, by creating the file with read/write permission > first and then revoking that permission in a separate call to aufs_setattr > if necessary. That's not perfect behavior (there is a window during which > the extended preliminary permissions are visible), but it appears to work.
>From my understanding, such window is problematic. As long as nfs4 has its ->atomic_open(), aufs should call it. The sequence of - open("file", O_CREAT|O_WRONLY, 0600); - open("file", O_WRONLY); - chmod("file", 0400); is not atomic at all from nfs4's point of view. My current idea is - At the point where my previous patch prints, aufs creates a small object of {pid, dentry} pair and holds internally. - In aufs_create(), return 0 without processing if given {pid, dentry} matches with the internally stored one. Otherwise, process normally. - In aufs_open(), calls ->atomic_open if {pid, dentry} matches. - The "exit notifier" may be necessary to free the internal pair, if the task can abort in lookup after aufs creates the internal pair. I don't think this idea is good, and still considering how to do it. Anyway, your patch is surely one approach. Thanx. J. R. Okajima ------------------------------------------------------------------------------ BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF