Subject: bug#75626: 31.0.50; Dired misses or double-processes files when auto-revert-mode is enabled

From: Eli Zaretskii <[email-masked]>
Date: Fri, 17 Jan 2025 14:17:09 +0200

> From: Tassilo Horn <[email-masked]>
> Cc: [email-masked]
> Date: Fri, 17 Jan 2025 10:04:25 +0100
> 
> Eli Zaretskii <[email-masked]> writes:
> 
> Hi Eli,
> 
> >> emacs -Q test
> >> M-x auto-revert-mode RET
> >> % m .* RET               ; mark all files
> >> Z                        ; compress them all
> >> Z                        ; uncompress them all again
> >> Z                        ; again and again...
> >> ...
> >> 
> >> I always wait until the (un)compress operations are all done before
> >> pressing Z again.  But even though, at some Z you will notice that
> >> your directory doesn't contain only gz or only non-gz files but a mix
> >> of both!
> >> 
> >> It seems the reason is that auto-revert-mode at some point reverts
> >> the buffer at random points in time while dired is still
> >> (un)compressing and that changes the order of files so that it either
> >> misses files or processes some files twice.
> >
> > What happens if you set auto-revert-use-notify to the nil value?
> 
> It seems that makes the bug even more likely to trigger.  Out ouf 3
> tests with my 100 files, even after just one Z operation, I had mixed gz
> and uncompressed files (starting from 100 uncompressed files).
> 
> > In any case, if you stop pressing 'Z', doesn't the list of files
> > eventually become up-to-date?
> 
> No, as said, after pressing Z, I always wait until the operation is
> done.  And I get final dired messages like
> 
>   Compress or uncompress: 162 files.
> 
> Well, there are exactly 100 files.  So it processed 62 files twice,
> compressing them first and then uncompressing them again (or skipped
> some and processed other even more).
> 
> > And if it does, why is this considered a bug?  The fact that
> > auto-revert-mode catching the directory in some intermediate state
> > from time, when files in the directory are being created and deleted,
> > to time should not come as a surprise, I think.  Or what am I missing?
> 
> Yes, that's no surprise.  But it should not cause files to be missed or
> double-processed, i.e., I would expect that dired initially captures all
> marked files and then processes them one by one.  But it looks like
> dired navigates the dired buffer marked file by marked file and when the
> sorting changes in between due to a refresh, it misses or
> double-processes files.

That's not how dired-do-* commands work, though.  So I think an easier
solution would be to temporarily disable auto-revert-mode while the
command runs.