[darcs-devel] Homebuilt darcs won't create temporary files

[David Roundy]

On Thu, Mar 03, 2005 at 04:28:31PM +0100, Josef Svenningsson wrote:
> I've managed to find the bug. It seems to be an off-by-one bug in the
> implementation of mkstemp for win32 in compat.c . But what I can
> understand is why nobody else has had problems with it. It is also
> slightly erratic because it interacts with the random numbers
> generated in mkstemp. Anyway I've attached a patch which solves the
> problem for me. The generated file names in mkstemp seems to be just
> as random as before as well.

This is odd.  Your patch essentially reverses the patch

Thu Jan 27 18:40:48 EST 2005  Jan-Benedict Glaw <jbglaw at lug-owl.de>
  * Fix off-by-one error in WIN32 version of mkstemp()
  
  This patch solves different issues with the mkstemp() funktion provided
  for WIN32 versions of darcs:
  
  - THIS PATCH IS NOT TESTED: I'VE GOT NO WINDOWS AROUND!
  - Move file-local variable into the mkstemp() since it's only used
    by mkstemp().
  - Remove unneeded variable p2.
  - Remove unneeded variable fd by directly returning the result of
    open().
  - Correctly return EINVAL if the supplied template isn't at least
    6 bytes long and doesn't end in 6 consecutive 'XXXXXX'.
  - Write 6 bytes of hex garbage instead of 5 bytes of decimal garbage.
    This was caused because the final \0 wasn't put into account for
    the snprintf() call.
M ./compat.c -10 +9

which didn't make it into darcs 1.0.2 because it was untested (and I
trusted that one of the win32 folks would ask for it if they thought it was
important).

But reading the man pages (both the GNU and BSD ones) on snprintf and
strlen, it looks to me like Jan-Benedict's code is correct.  The length 7
includes the room for the null character, while the output of strlen
doesn't include the null character.  :(

But of course, what matters is what actually happens.  Could it be that on
your system (or possibly all win32 systems?) snprintf or strlen is behaving
differently from how it's expected to behave on linux and MacOS X (the two
systems I personally own)?

Okay, I've gone ahead and looked this up:

http://www.di-mgt.com.au/cprog.html#snprintf

It seems that microsoft's snprintf has no guarantee of resulting in a
null-terminated string, so we want to make the length one less to keep it
from overwriting the terminating null character, which would be very bad.
I'll apply your patch and then add a comment to explain this interesting
behavior.

> Btw, it seems that the random numbers generated in mkstemp are pseudo
> random. I get the same sequence each time I run darcs. This seems like
> a small but potential problem.

We seed the random number generator with the time, which is obviously not a
strong random number, but ought to give *some* variation.  Perhaps time is
also subtly different on windows? In posix, it returns the number of
seconds since the epoch.

> Now, I can *finally* start testing the put command.

Woo hoo! :)
-- 
David Roundy
http://www.darcs.net