[Fdo-trac] [fdo-trac] #1007: Replace usage of tempnam with mkstemp in FdoCommonFile

[FDO]

#1007: Replace usage of tempnam with mkstemp in FdoCommonFile
---------------------+----------------------
 Reporter:  jng      |        Owner:  jng
     Type:  task     |       Status:  closed
 Priority:  major    |    Milestone:  4.2.0
Component:  FDO API  |      Version:
 Severity:  3        |   Resolution:  fixed
 Keywords:           |  External ID:
---------------------+----------------------
Changes (by jng):

 * resolution:   => fixed
 * status:  assigned => closed

Comment:

 In [changeset:"8372" 8372]:
 {{{#!CommitTicketReference repository="" revision="8372"
 FdoCommonFile::GetTempFile(): Generate the temporary name with mkstemp()
 instead of tempnam()

 tempnam() has been deprecated for decades because the name it returns can
 be stolen
 between the call and the caller's own open() - GCC warns about it on every
 link of every
 provider and the suite that actually uses the function ("the use of
 `tempnam' is
 dangerous, better use `mkstemp'"). The POSIX branch of GetTempFile() now
 builds an
 "<directory>/idfXXXXXX" template and hands it to mkstemp(), which creates
 the file with
 owner-only permissions and returns a name nothing else can have taken.

 The file mkstemp() creates is closed and unlinked before returning, so the
 name still
 comes back in the same "unique, but not created yet" state that the
 Windows branch
 already returns: that branch calls GetTempFileName() and then deletes what
 it made, and
 the callers (ShpFileSet, ShpSpatialIndex and ShapeIndex) open - and so
 create - the name
 themselves, some of them with IDF_CREATE_NEW, which fails if the file is
 already there.
 Leaving the file in place would have been a contract change, so it is
 removed as well as
 created; the alternative of not creating it at all is what tempnam() did
 and what the
 warning is about.

 Behaviour is otherwise unchanged: the given directory is used when there
 is one (a
 missing or unwritable directory now fails here rather than at the caller's
 open, which is
 what the return value documents), an empty path falls back to TMPDIR and
 then P_tmpdir
 the way tempnam(NULL, ...) did, the name keeps its "idf" prefix and is
 still allocated
 with new[] for the caller to delete[], and a failure still returns false
 with errno set.

 Verified against the built library: the returned name is in the requested
 directory, does
 not exist, is unique across calls, can be created with O_CREAT|O_EXCL and
 with
 FdoCommonFile::OpenFile(IDF_OPEN_UPDATE|IDF_CREATE_NEW), and nothing is
 left behind in the
 temporary directory. The SHP suite - the only suite that reaches
 GetTempFile, through the
 spatial index and fileset temporary-file fallbacks - is still green (OK
 (138)) with no
 leaks, and the FDO Core suite is unchanged (OK (123)).

 Fixes #1007
 }}}
-- 
Ticket URL: <https://trac.osgeo.org/fdo/ticket/1007#comment:1>
FDO <http://fdo.osgeo.org/>
Feature Data Objects