On Thu, Feb 1, 2024 at 12:29 PM Miklos Szeredi <miklos@xxxxxxxxxx> wrote: > > On Thu, 1 Feb 2024 at 11:16, Amir Goldstein <amir73il@xxxxxxxxx> wrote: > > > I can look into it, but for now the fix to fuse_sync_release() is a simple > > one liner, so I would rather limit the changes in this series. > > Not urgent, but it might be a good idea to add a cleanup patch as a > prep, which would make this patch just that one line less complex. > I will see if I can get something done quickly. > > Is fuse_finish_open() supposed to be called after clearing O_TRUNC > > in fuse_create_open()? > > This will invalidate size/modification time, which we've just updated > with the correct post open values. > > > I realize that this is what the code is doing in upstream, but it does not > > look correct. > > I think it's correct, because it deals with the effect of > FUSE_OPEN/O_TRUNC on attributes that weren't refreshed in contrast to > fuse_create_open() where the attributes were refreshed. > I was considering splitting fuse_finish_open() to the first part that can fail and the "finally" part that deals with attributes, but seeing that this entire chunk of atomic_o_trunc code in fuse_finish_open() is never relevant to atomic_open(), I'd rather just move it out into fuse_open_common() which has loads of other code related to atomic_o_trunc anyway? Thanks, Amir. > Thanks, > Miklos
