bug#51523: 29.0.50; gnus-mime-view-part-externally very slow

[Gregory Heytings]

I attach an improved version of file-has-changed-p.  Following Eli's 
suggestion, it records the file size together with its timestamp.

Stefan:
> This API doesn't seem safe.
>
> If two packages read&parse the same file and both rely on this function 
> to decide when to reparse, the second package can get a nil value 
> (because the first has caused the mtime to be reset in the hash table) 
> even though the file has changed since it last parsed it.

I agree with you, and added a second optional "tag" argument to the 
function, in which one can for example pass the name of the calling 
function, or the name of the library.  It's the responsibility of the 
caller to use the tag they want.

Eli:
> What would be the purpose of replacing with an older file, but keeping 
> the old time stamp?  And why is Gnus obligated to support such strange 
> use cases?  We can always tell the users to bump the file's time stamp 
> by 'touch'ing it, no?

It's not a strange use case at all.  For example, you make a backup of 
your ~/.mailcap file, make some changes in the original file, decide that 
after all they're not what you want, and do mv ~/.mailcap.bak ~/.mailcap.

> But the real answer to that question is to compare the contents, not 
> file's attributes.  Testing attributes is an approximation, and once we 
> are using an approximation, it is legitimate to ask when it's okay for 
> the approximation to fail.

It's an approximation indeed, but it's a very safe one.  It's what rsync 
uses, and I haven't seen a single case in which it failed to do TRT in 
twenty years or so.  The likelihood that a file with the exact same 
filename, same size and same timestamp have different contents is, in 
practice, zero.  It is of course possible to cheat that detection 
mechanism, but only if you do it on purpose.

Improve-file-has-changed-p.patch
Description: Text Data