[DVIPDFMx] regression with dvipdfmx-20090506 and later

[Jukka Salmi]

Hello,

Matthias Franz --> dvipdfmx (2009-08-12 10:36:56 +0900):
> Hello Jukka,
> 
> although this problem might be encountered more often with the latest
> release of dvipdfmx, it seems to me that it is not caused by our code.
> 
> On Tue, Aug 11, 2009 at 10:32:00PM +0200, Jukka Salmi wrote:
> > While running dvipdfmx with -vv I noticed that temporary file names are
> > recycled as soon as all 26 lowercase latin letters have been used:
> 
> It looks as if the mkstemp function on your system cannot create more
> than 26 distinct file names per process. What is the value of TMP_MAX
> (the minimum number of unique filenames) on your system? On my Linux box,
> mkstemp uses all 6 "X"'s to get a unique filename, and TMP_MAX == 238328.

TMP_MAX is 26^6 on NetBSD, but it's not used by mkstemp(3).  However,
with six 'X' in the template string, 26^6 unique file names will be
generated, so that should not be the problem.

But if the temporary files whose names mkstemp(3) generates do not
exist, file names are recycled after 26 of them.  And that's what
happens with dvipdfmx IIUC:

1) A temporary file name (e.g., /tmp/dvipdfmx.12345a) is obtained by
   calling mkstemp().
2) The file is opened, used and unlinked.
3) Steps 1) and 2) are repeated until filename is /tmp/dvipdfmx.12345z.
4) Since /tmp/dvipdfmx.12345a does not exist, that's the next file name
   obtained by calling mkstemp().

I don't understand why this file name recycling should be a problem;
dvipdfmx seems to process those temporary files serially, opening file i
only after file i-1 has been unlinked.  Thus it should even succeed if
mkstemp(3) always returned the same file name...  What am I missing?

BTW, dvipdfmx should probably not close the fd returned by mkstemp(3)
and then open the file by name, but that's another problem...


> > BTW, this is on a NetBSD/i386 5.0 system with a TeX Live 2009 pretesting
> > release.
> 
> Some googling seems to indicate that this is a problem with NetBSD.
> If that's true, then the question is whether we should change our code
> to accomodate for a poor implementation of mkstemp.

If that's the case dvipdfmx should not be changed IMHO...  But I doubt
it ;-)


Regards, Jukka

-- 
This email fills a much-needed gap in the archives.