On Mon, Nov 7, 2022 at 6:38 AM YoungJun.Park <her0gyugyu@xxxxxxxxx> wrote: > > Here is my curious scenario. > > 1. create a file on overlayfs. > 2. delete a file on upper directory. > 3. can see file contents using read sys call. (may file operations all success) > 4. cannot remove, rename. it return -ESTALE error (may inode operations fail) > > I understand this scenario onto the code level. > But I don't understand this situation itself. > > I found a overlay kernel docs and it comments > Changes to underlying filesystems section > > ... > Changes to the underlying filesystems while part of a mounted overlay filesystem are not allowed. > If the underlying filesystem is changed, the behavior of the overlay is undefined, > though it will not result in a crash or deadlock. > .... > > So here is my question (may it is suggestion) > > 1. underlying file system change is not allowed, then how about implementing shadow upper directory from user? > 2. if read, write system call is allowed, how about changing remove, rename(and more I does not percept) operation success? > What is your use case? Why do you think this is worth spending time on? If anything, we could implement revalidate to return ESTALE also from open in such a case. But again, why do you think that would matter? Thanks, Amir.
