<div class="gmail_quote">On Thu, Dec 2, 2010 at 23:19, Matthew Knepley <span dir="ltr"><<a href="mailto:knepley@gmail.com">knepley@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div>How exactly does that happen? I have just checked that I ran multiple configures and did not clobber those logs.</div></blockquote><div><br></div><div>When a new configure process starts, it truncates the file.  You only relocate it later.  It's a race condition, so may not happen every time, or you might not have correct contents in each of your files.</div>
<div>  </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im"><div></div></div><div>I do not think this works on NTFS.</div></blockquote></div><br><div>
NTFS is lame and does not have a way to atomic rename when the destination file exists.  But it does have both hardlinks and symlinks.  In the proposed model $PETSC_DIR/configure.log is only a convenience for the user, it is not being read or written concurrently, so the fact that redirecting the symlink cannot be done atomically should not be a problem (racing a human is safer than racing another process).</div>
<div><br></div><div>Jed</div>