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 #11 received at 75626 <at> debbugs.gnu.org (full text, mbox):

From: Tassilo Horn <tsdh <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 75626 <at> debbugs.gnu.org
Subject: Re: bug#75626: 31.0.50; Dired misses or double-processes files when
 auto-revert-mode is enabled
Date: Fri, 17 Jan 2025 10:04:25 +0100

Eli Zaretskii <eliz <at> gnu.org> 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.

Maybe Z is special in that the files are renamed (.gz suffix gone or
added) but keep their mark.  I wonder what would happen if Z would not
just rename but add another file that also would be marked so that the
set of marked files grows with each operation.  In that case, I assume
it would never finish.

Bye,
  Tassilo

Previous Next

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