RejectedSoftware Forums

Sign up

Logfiles: Overwrite vs Append?

I noticed that the log files (as set by setLogFile()) are being opened
for overwrite rather than append. Is that an oversight or is there a
specific reason for that?

If intended, would it make sense to put together a pull request that
adds an optional extra param to setLogFile() to optionally make it
append?

Re: Logfiles: Overwrite vs Append?

Am 13.02.2013 09:26, schrieb Nick Sabalausky:

I noticed that the log files (as set by setLogFile()) are being opened
for overwrite rather than append. Is that an oversight or is there a
specific reason for that?

If intended, would it make sense to put together a pull request that
adds an optional extra param to setLogFile() to optionally make it
append?

Appending is definitely the intention, setLogFile looks like this:

void setLogFile(string filename, LogLevel min_level = LogLevel.Error)
{
	s_logFile = openFile(filename, FileMode.Append);
	s_logFileLevel = min_level;
}

On which platform does it overwrite instead?

Re: Logfiles: Overwrite vs Append?

On Wed, 13 Feb 2013 10:23:02 +0100
Sönke Ludwig sludwig@rejectedsoftware.com wrote:

Am 13.02.2013 09:26, schrieb Nick Sabalausky:

I noticed that the log files (as set by setLogFile()) are being
opened for overwrite rather than append. Is that an oversight or is
there a specific reason for that?

If intended, would it make sense to put together a pull request that
adds an optional extra param to setLogFile() to optionally make it
append?

Appending is definitely the intention, setLogFile looks like this:

void setLogFile(string filename, LogLevel min_level = LogLevel.Error)
{
	s_logFile = openFile(filename, FileMode.Append);
	s_logFileLevel = min_level;
}

On which platform does it overwrite instead?

Win32. Haven't tried on others yet,

Re: Logfiles: Overwrite vs Append?

On Wed, 13 Feb 2013 10:23:02 +0100
Sönke Ludwig sludwig@rejectedsoftware.com wrote:

Am 13.02.2013 09:26, schrieb Nick Sabalausky:

I noticed that the log files (as set by setLogFile()) are being
opened for overwrite rather than append. Is that an oversight or is
there a specific reason for that?

If intended, would it make sense to put together a pull request that
adds an optional extra param to setLogFile() to optionally make it
append?

Appending is definitely the intention, setLogFile looks like this:

void setLogFile(string filename, LogLevel min_level = LogLevel.Error)
{
	s_logFile = openFile(filename, FileMode.Append);
	s_logFileLevel = min_level;
}

On which platform does it overwrite instead?

Wait, no. I think I screwed up my testing of it and misinterpreted
the results. Looks like you can only set one log file, right? If you
call setLogFile again with a different filename, that changes to file
being logged to, it doesn't make it also log to that right? If so
then it's my dumb mistake and everything's working as it should.

Re: Logfiles: Overwrite vs Append?

Am 13.02.2013 13:32, schrieb Nick Sabalausky:

On Wed, 13 Feb 2013 10:23:02 +0100
Sönke Ludwig sludwig@rejectedsoftware.com wrote:

Am 13.02.2013 09:26, schrieb Nick Sabalausky:

I noticed that the log files (as set by setLogFile()) are being
opened for overwrite rather than append. Is that an oversight or is
there a specific reason for that?

If intended, would it make sense to put together a pull request that
adds an optional extra param to setLogFile() to optionally make it
append?

Appending is definitely the intention, setLogFile looks like this:

void setLogFile(string filename, LogLevel min_level = LogLevel.Error)
{
	s_logFile = openFile(filename, FileMode.Append);
	s_logFileLevel = min_level;
}

On which platform does it overwrite instead?

Wait, no. I think I screwed up my testing of it and misinterpreted
the results. Looks like you can only set one log file, right? If you
call setLogFile again with a different filename, that changes to file
being logged to, it doesn't make it also log to that right? If so
then it's my dumb mistake and everything's working as it should.

Yes, that's correct. I wanted to heavily extend the flexibility of the logger at some point, though
(we have another, more flexible logger internally and those need to be merged). It was just put on
hold because of the now seemingly abandoned std.log.