Re: Update cache files atomically.

[Ralf Wildenhues]

Hi Eric,

* Eric Blake wrote on Wed, Oct 08, 2008 at 03:51:46AM CEST:
> According to Ralf Wildenhues on 10/7/2008 2:29 PM:
> > 
> > -    cat confcache >$cache_file
> > +      if test -f "$cache_file"; then
> > +   mv -f confcache "$cache_file"
> 
> That's only atomic if $cache_file resides on the same device as `.' (and
> even then, there are deficient file systems like sshfs that can't even do
> cross-directory renames, even when both directories are on the same device).

Well, yes, it's only atomic in the common case where the cache file was
created on the same device.  That's what happens with the vast majority
of builds though (I would assume).

> > +      else
> > +   cat confcache >"$cache_file"
> 
> And that's still racy: consider what happens if process1 starts the cat
> process, then process2 sees that the file exists and does the mv, then
> process1 completes the cat.  Rather than making this truly atomic, you've
> only reduced how often the conflict happens.

If $cache_file did not exists at the time the first configure script
started, it would have created it much earlier, in AC_CACHE_LOAD.
The distinction above is only to work well when $cache_file is not a
regular file.

> So based on that, and on your observation that people generally don't set
> shared config.cache, I'm inclined to pass on this for now, leaving the
> mail archive as sufficient for anyone who thinks otherwise.  Maybe it's
> safer to always 'cp confcache "$cache_file.tmp"', then 'mv
> "$cache_file.tmp" "$cache_file"', and skip the cat?  I'm welcome to
> further arguments for inclusion or a more robust patch, but am not
> bothered enough by it to spend time on it myself.

Again, the cat is not the problem, the mv is, if the device is different
or the fs is borked (the latter I hope to ignore until the first bug
report).

Let's leave it at that for now.

Cheers, and thanks for the review,
Ralf