On Aug 21, 2020 Miklos Szeredi <miklos@xxxxxxxxxx> wrote: > On Thu, Aug 20, 2020 at 12:24 AM Ken Schalk <kschalk@xxxxxxxxxx> wrote: > > If the open flags include O_EXCL, then we're seeing a failure with > > EEXIST without any call to our FUSE filesystem's create operation (or > > any other FUSE operations). The kernel makes this failure decision > > based on its cached information about the previously accessed (now > > deleted) file. If the open flags do not include O_EXCL, then we're > > seeing a failure with ENOENT from our open operation (because the file > > does not actually exist anymore), with no call to our create operation > > (because the kernel believed that the file existed, causing it to make > > a FUSE open request rather than a FUSE create request). > Does the attached patch fix it? Thanks very much for your help. The patch you provided does solve the problem in the O_CREAT|O_EXCL case (by making a lookup call to re-validate the entry of the since deleted file), but not in the O_CREAT case. (In that case the kernel still winds up making a FUSE open request rather than a FUSE create request.) I'd like to suggest the slightly different attached patch instead, which triggers re-validation in both cases. I wonder if maybe re-validation should be triggered on LOOKUP_OPEN as well, but I suspect that might have more implications I haven't discovered. --Ken Schalk
Attachment:
fuse-reval-create.patch
Description: fuse-reval-create.patch
