Re: Try to update config.cache atomically; respect symlinks.

[Ralf Wildenhues]

Hi Eric,

* Eric Blake wrote on Sat, Aug 14, 2010 at 07:20:45PM CEST:
> On 08/14/2010 12:32 AM, Ralf Wildenhues wrote:
> > This patch fixes a long-standing issue GCC has with Autoconf: cache
> > files are not updated atomically.  (This was IIUC the primary reason
> > GCC introduced per-configure cache files.)

> > There's a small chance of a leftover file in the directory where the
> > cache file resides, when a signal arrives at the right time.  Not sure
> > if that's worth changing the exit trap, that wasn't done for the
> > 'confcache' file either; but of course, the latter would be cleaned up
> > after another configure run.  OTOH, the exit trap could then open up a
> > symlink attack upon '--cache-file=/tmp/config.cache'.
> 
> Is it worth documenting that such a scratch file is safe to delete?

Hey, I was trying to get you to decide all the hard questions!  ;-)
I'm really reluctant to admit defeat in public, as in:

   * doc/autoconf.texi (Cache Files): Leftover temporary cache
   files may be deleted by the user.

diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index 95e43f2..409dcbb 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -9801,6 +9801,12 @@ results with the existing cache file.)  This may cause 
problems,
 however, if the system configuration (e.g., the installed libraries or
 compilers) changes and the stale cache file is not deleted.
 
+If @command{configure} is interrupted at the right time when it updates
+a cache file outside of the build directory where the @command{configure}
+script is run, it may leave behind a temporary file named after the
+cache file with digits following it.  You may safely delete such a file.
+
+
 @node Cache Checkpointing
 @subsection Cache Checkpointing
 

folded in my previous patch.  I'm not sure if we can do better safely.
The problem with /tmp is the sticky bit.  test -k is not portable.
Something like
  find $dir_of_cache_file -prune -perm -1000 -print

can help, but then there are the various details of how /tmp and sticky
works on other systems, and I have no idea what to look out for on w32
...

> > +++ b/tests/base.at

> > +# Using a symlinked cache file works.
> > +: > cache
> > +rm -f config.cache
> > +AS_LN_S([cache], [config.cache])
> > +AT_CHECK_CONFIGURE([-C])
> > +AT_CHECK([test -s cache || test ! -h config.cache])
> 
> Will this test work on mingw, which lacks symlinks?

Yes.  I verified that now on MSYS and Cygwin.

> Do we need to add an extra check before AT_CHECK_CONFIGURE that skips
> if config.cache is not a symlink?

No, because the last AT_CHECK is designed to catch both cases.  I've
added a comment to this end now, see below.

Thanks,
Ralf

diff --git a/tests/base.at b/tests/base.at
index 732ff1b..03c61b7 100644
--- a/tests/base.at
+++ b/tests/base.at
@@ -462,6 +462,8 @@ AT_CHECK([LC_ALL=C ls -t config.cache a-stamp-file | sed 1q 
| grep config.cache]
 rm -f config.cache
 AS_LN_S([cache], [config.cache])
 AT_CHECK_CONFIGURE([-C])
+# Either the system does not support symlinks, or the symlinked-to file
+# should be updated.
 AT_CHECK([test -s cache || test ! -h config.cache])
 
 # config.site can specify a site-wide cache, accumulating information.