Re: copy_file_range() doesn't update the atime of an empty file

On Thu, Oct 5, 2023 at 6:53 PM Rick Macklem <rick.macklem@gmail.com> wrote:
>
> On Thu, Oct 5, 2023 at 3:30 PM Rick Macklem <rick.macklem@gmail.com> wrote:
> >
> > On Thu, Oct 5, 2023 at 8:41 AM Alan Somers <asomers@freebsd.org> wrote:
> > >
> > > I don't think that Linux is a good model to copy from, where atime is
> > > concerned.  It long ago gave up on POSIX-compliance for atime by
> > > default.  In this case, I think it's better to stick as closely as we
> > > can to read(2).  Preserving the existing behavior of tools like cat,
> > > too, is worthwhile I think.
> > I have no problem with Mark's patch being applied for the default
> > local fs case.  NFSv4.2 will not be able to comply with this unless
> > (as will be the case for the FreeBSD server) the NFSv4.2 server
> > happens to change atime after Mark's patch is applied to the
> > FreeBSD NFSv4.2 server (the Linux NFSv4.2 server will not).
> I have come up with a NFSv4.2 client patch that explicitly sets atime
> for the input file in the same compound RPC as the Copy.  It works for
> a FreeBSD server without Mark's patch.  If a NFSv4.2 server does not
> do it, we can argue that the server ignores the Setattr of atime.
>
> So, with this patch (which I will be testing against assorted servers next
> week (an ietf bakeathon testing event) and Mark's patch, the only case
> that may need more work is ZFS?
>
> rick
> ps: I'll admit I still doubt anyone cares about atime being set, but the
>       collective opinion seems to be that it should be set.

I think the fusefs copy_file_range will already do this, but I should
at least add a test for it.
-Alan