GNU bug report logs - #75626
31.0.50; Dired misses or double-processes files when auto-revert-mode is enabled

Previous Next

Full log

Message #160 received at 75626 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: michael_heerdegen <at> web.de, 75626 <at> debbugs.gnu.org, tsdh <at> gnu.org
Subject: Re: Re: bug#75626: 31.0.50; Dired misses or
 double-processes files when auto-revert-mode is enabled
Date: Mon, 20 Jan 2025 21:44:46 +0200

> From: Drew Adams <drew.adams <at> oracle.com>
> CC: "tsdh <at> gnu.org" <tsdh <at> gnu.org>,
>         "michael_heerdegen <at> web.de"
> 	<michael_heerdegen <at> web.de>,
>         "75626 <at> debbugs.gnu.org" <75626 <at> debbugs.gnu.org>
> Date: Mon, 20 Jan 2025 19:31:34 +0000
> 
> > > An operation on marked files - which really
> > > means, for this macro, an operation on marked
> > > _lines_, CAN DO ANYTHING.
> > 
> > Auto-reverting is not something the operation on files does, it is
> > something that happens behind the operation's back.
> 
> Yes (though the macro doesn't necessarily invoke
> any operation on files).
> 
> And auto-reverting could occur while the macro is
> iterating over the marked lines, and while it's
> invoking its ARG function with point on a given
> line.
> 
> And yes, that can be a bother, and it's usually
> _not_ what you want or expect.  Agreed on all of
> that.  Is it _always_ not what you want/expect?

Yes.  Because the only way this macro can work predictably and
reliably is if it works on a snapshot of the directory's state.  It
cannot allow changed in the files that its body did not cause and does
not know about.

> > It affects the list of files that the operation
> > wants to map over, and could easily cause the
> > operation to never terminate.
> 
> Yes, I can see that.  I'd suggest letting that
> happen, by default, and add a note in the doc
> telling you how you can prevent that when/where
> you _call_ the macro.

If features like auto-revert are allowed to run during the macro's
operation, there's _nothing_ you can do to prevent these problems.
That's what the discussion of this bug reveals.

> That's my only disagreement.  I don't see that
> fixing the bug requires changing the macro's
> behavior in a general way.

Because otherwise the macro itself has a bug that cannot be possibly
fixed in the body.

> OTOH, if you make that change, is there some
> way for a user to modify the behavior for a
> given macro call, to _allow_ what would now be
> prevented in a general way?

No, and neither should there be such a way.  That way is a way of
introducing bugs into a program, and we don't write code that produces
buggy behavior.

> If there's no way for a user to override the
> behavior to be newly imposed then that seems
> a shame, to me.

I challenge you to come up with a problem whose solution requires to
allow auto-revert to modify the list of files while the macro runs.
If you can come up with such a problem, we could then discuss this and
see what followup changes might be needed.  Otherwise, I see no reason
to continue this discussion, since we are talking about problems that
don't exist in practice, AFAIK.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.