[mapserver-dev] RFC 66 - Better handling of temporary files

[Alan Boudreault]

Well the best thing would have been to use mkstemp() and something similar on 
windows that also returns a file handle. However, Windows doesn't seem to have 
this kind of function. We'll have to use GetTempFileName(), which only return 
a *unique* file name. We have to create the file ourself. This is not as safe 
as mkstemp(). So, something I am thinking about is to create a new function 
that will use mkstemp() on Linux/Mac and GetTempFileName() + fopen(..) on 
Windows. I'm afraid I don't have any Windows dev environment to test it. Could 
anyone help me on this when I finish the Linux part?


regards,
Alan


On January 17, 2011 10:03:26 am Alan Boudreault wrote:
> I understand your concern and I agree. I Will check to use those functions
> by default. I also agree that if the user set the TEMPPATH, this path will
> be used rather than the default system path.
> 
> regards,
> Alan
> 
> On January 14, 2011 04:42:27 pm thomas bonfort wrote:
> > On Fri, Jan 14, 2011 at 22:23, Frank Warmerdam <warmerdam at pobox.com> 
wrote:
> > > On 11-01-14 07:46 AM, thomas bonfort wrote:
> > >> Jeff,
> > >> I don't like TEMPPATH because it should not be necessary for a user to
> > >> have to configure it. On unix, there is a system function that will
> > >> guarantee to create you a temp file without having to make the
> > >> assumption it will be in /tmp, and I imagine it could be possible to
> > >> implement something similar for windows if it doesn't exist.
> > >> Let's not burden our users with setting a configuration variable for
> > >> something that is system related and should be taken care of
> > >> transparently.
> > > 
> > > Thomas,
> > > 
> > > I like the idea of being able to control where my MapServer temp
> > > files are created - either so I can keep them separate from system
> > > temporary files, or so I can control what drive they are on (ie.
> > > ram drive, extra physical drive).  But it might be nice if the
> > > *fallback* when it isn't set is to do the normal system behavior.
> > 
> > Frank,
> > as a developer, I agree that knowing where the temp file is created so
> > you can inspect what is going on is a definitive plus. As a user, I
> > don't see the point, and would especially not want to have to
> > configure it.
> > I'm +1 for a default system call if TEMPPATH is not specified and use
> > whatever defined value if the user has gone to the trouble of
> > specifying it, and against having a log message
> > be output if TEMPPATH is not set.
> > My initial concern is that we seem to be reinventing the wheel in
> > regards to tempfile creation, whereas there are secure and tested
> > solutions with mkstemp that we should at least investigate before
> > rolling out our own.
> > 
> > best regards,
> > thomas
> > 
> > ps. I hope the tone is not harsh or condescending, its not my aim in any
> > way. _______________________________________________
> > mapserver-dev mailing list
> > mapserver-dev at lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/mapserver-dev

-- 
Alan Boudreault
Mapgears
http://www.mapgears.com