[mapserver-users] Re: FastCGI and trouble writing to the MS_ERRORFILE

[Daniel Morissette]

Frank Warmerdam wrote:
> 
> It might also be necessary to modify the debug output code to always
> try and seek to the end of file before writing.  If several long running
> fastcgi processes have the same log file open and are writing to it, we
> could have an issues of overwriting each others output.
> 

At first I thought this was a serious issue, but then after a bit of 
research I found out that the most common platforms we work with seem to 
handle that for us already.

The Linux man page for fopen says:
------------------------------------------------------
Opening a file in append mode (a as the first character of mode) causes
all subsequent write operations to this stream to occur at end-of-file,
as if preceded by an
     fseek(stream,0,SEEK_END);
call.


The following is from the man page of fopen ( on Solaris 9 )
(found here: http://bytes.com/forum/thread215699.html)
------------------------------------------------------
Opening a file with append mode (a as the first character in
the mode argument) causes all subsequent writes to the file
to be forced to the then current end-of-file, regardless of
intervening calls to fseek(3C). If two separate processes
open the same file for append, each process may write freely
to the file without fear of destroying output being written
by the other. The output from the two processes will be
intermixed in the file in the order in which it is written.

And here I found a ref to what looks like a Digital Unix man page giving 
a similar guarantee:
http://www.uwm.edu/cgi-bin/IMT/wwwman?topic=fopen(3)&msection=
------------------------------------------------------
[DIGITAL]  If two separate processes open the same file for append, each
process can write freely to the file without destroying the output being
written by the other. The output from the two processes is intermixed in
the order in which it is written to the file. Note that if the data is
buffered, it is not actually written until it is flushed.


Unfortunately I could not find anything about Windows, but there were 
never reports of such issues in the past on Windows that may not be a 
problem there either. In conclusion, while there might still be systems 
where the issue is present, I think we can safely ignore the issue and 
cross the bridge if/when someone encounters it.

Daniel
-- 
Daniel Morissette
http://www.mapgears.com/