W3C home > Mailing lists > Public > www-lib@w3.org > July to September 1997

HTCache and tmpnam() on NT 4.0

From: Rick Kwan <kenobi@NetPhonic.COM>
Date: Wed, 23 Jul 1997 14:42:02 -0700
Message-Id: <199707232142.OAA19316@NetPhonic.COM>
To: www-lib@w3.org
Wonder if anyone has run into this or not...

I have been working on NT 4.0 with MSVC++ 4.2.  When my browser
goes into HTCache_findName(), it calls HTGetTmpFileName() and attempts
to generate a name.  The first result that comes back is "\s54.".
This is later used to identify a file in the cache directory.

However, when the file gets created, it has a name "s54", while its
meta file is "s54..meta".  (An entry also shows up for it in ".index".)
Hence, when the browser later discovers that the cache entry should
exist, but is permanently unable to retrieve it.

The name "\s54." came from C's all-purpose tmpnam(), which I presume is
in the C run-time library (DLL) on NT 4.0.  Later, when the cache file
is created, NT 4.0 truncates the period (".").  The next round through
tmpnam() generates "\s54.1", and then "\s54.2".  Only the first one
will be truncated.  However, the period-terminated seems to be
guaranteed to happen at least once per session.

(On UNIX, of course, there are no periods in the generated name, and they
don't matter anyway.  So, I never have the problem there.)

I am curious...
    Has anyone run into this?
    Has this been fixed in MSVC++ 5.0, or is this an NT problem?
    Does tmpnam_r() have the same problem?  (I did not compile with
	HT_REENTRANT.)
    This is too silly; am I missing something???

--Rick Kwan, NetPhonic Communications
  rick.kwan@NetPhonic.COM
Received on Wednesday, 23 July 1997 17:45:38 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 23 April 2007 18:18:27 GMT