bug-findutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [bug #33724] Find command is changing the access time of directory


From: James Youngman
Subject: Re: [bug #33724] Find command is changing the access time of directory
Date: Sat, 29 Sep 2018 21:37:03 +0100

Re-reading the text I wrote, I see that some critical words were missing:

> Reserving the option doesn't seem especially helpful, either

I meant, reserving the option as being for use only by the root user (for
whom one might imagine the EPERM issue would not arise) does not seem
especially helpful.

> (and may not work over NFS or other remote filesystems where root is
squashed).


On Sat, Sep 29, 2018 at 8:30 AM James Youngman <address@hidden> wrote:

> Having a "don't update atime" option that only works sometimes (when I
> own the directory) seems problematic to me.
>
> If the user specifies the "keep access time unchanged" option and we
> can't honour it (because there is at least one directory that they
> don't own) what should we do?
>
> We can't simply abort at the time the error is detected, since we have
> searched some of the file system, and possibly generated some side
> effects.     But perhaps the user would not want us to continue
> either.   Reserving the option doesn't seem especially helpful, either
> (and may not work over NFS or other remote filesystems where root is
> squashed).
>
> In short, I can't see a way of making such an option non-user-surprising.
>
> On Sat, Sep 29, 2018 at 3:09 AM Bernhard Voelker
> <address@hidden> wrote:
> >
> > Follow-up Comment #3, bug #33724 (project findutils):
> >
> > [CC-ing gnulib, in the hope they see the attachment as well.]
> >
> > On Sun 01 Nov 2015 11:19:53 PM CET, James Youngman wrote:
> > > It looks like the FTS_NOATIME flag does what's needed.
> >
> > Not quite: openat() returns with EPERM if:
> >
> >   $ man openat | grep EPERM.*NOATIME
> >        EPERM  The O_NOATIME flag was specified, but the effective user
> ID of
> > the caller \
> >               did not match the owner of the file and the caller was not
> > privileged.
> >
> > Indeed, when quickly adding FTS_NOATIME to ftsoptions in ftsfind.c for
> > testing,
> > then strace in a directory not owned by the calling (non-root) user
> shows:
> >
> >   openat(AT_FDCWD, ".",
> > O_RDONLY|O_NOCTTY|O_NONBLOCK|O_NOFOLLOW|O_NOATIME|O_CLOEXEC|O_DIRECTORY)
> = -1
> > EPERM (Operation not permitted)
> >
> > and find issues an error diagnostic.
> >
> > It seems that O_NOATIME cannot be used generally on directories.
> > Conversely it seems that the atime of such a directory is changed
> > without a problem.
> >
> > The attached path makes FTS retry without O_NOATIME in such a case
> > which seems to be the best choice we currently have.
> > Once this is working in FTS, we need to decide how to enable/disable
> > the NOATIME behaviour in find(1), as POSIX requires this per default.
> >
> > WDYT?
> >
> > Have a nice day,
> > Berny
> >
> >
> >
> >
> > (file #45115)
> >     _______________________________________________________
> >
> > Additional Item Attachment:
> >
> > File name:
> 0001-fts-opendirat-fall-back-to-O_NOATIME-in-case-of-EPER.patch
> > Size:2 KB
> >
> >
> >     _______________________________________________________
> >
> > Reply to this item at:
> >
> >   <https://savannah.gnu.org/bugs/?33724>
> >
> > _______________________________________________
> >   Message sent via Savannah
> >   https://savannah.gnu.org/
> >
>
>
> --
> --
> This email is intended solely for the use of its addressee, sender,
> and any readers of a mailing list archive in which it happens to
> appear.   If you have received this email in error, please say or type
> three times, "I believe in the utility of email disclaimers," and then
> reply to the author correcting any spellings (and, optionally, any
> incorrect spellings), accompanying these with humorous jests about the
> author's parentage.   If you are not the addressee, you are
> nevertheless permitted to both copy and forward this email since
> without such permissions email systems are unable to transmit email to
> anybody, intended recipient or not.  To those still reading by this
> point, the author would like to apologise for being unable to maintain
> a consistent level of humour throughout this disclaimer.  Contents may
> settle during transit.  Do not feed the animals.
>


-- 
--
This email is intended solely for the use of its addressee, sender, and any
readers of a mailing list archive in which it happens to appear.   If you
have received this email in error, please say or type three times, "I
believe in the utility of email disclaimers," and then reply to the author
correcting any spellings (and, optionally, any incorrect spellings),
accompanying these with humorous jests about the author's parentage.   If
you are not the addressee, you are nevertheless permitted to both copy and
forward this email since without such permissions email systems are unable
to transmit email to anybody, intended recipient or not.  To those still
reading by this point, the author would like to apologise for being unable
to maintain a consistent level of humour throughout this disclaimer.
Contents may settle during transit.  Do not feed the animals.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]