[Top][All Lists]

[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 08:30:59 +0100

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

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, ".",
> 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.
> 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.

reply via email to

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