[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Try to update config.cache atomically; respect symlinks.
From: |
Ralf Wildenhues |
Subject: |
Re: Try to update config.cache atomically; respect symlinks. |
Date: |
Mon, 16 Aug 2010 22:03:35 +0200 |
User-agent: |
Mutt/1.5.20 (2010-04-22) |
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.