Enhance the can.logger to check to see if the log file exists and append if there rather than overwrite

[j-c-cook]

Is your feature request related to a problem? Please describe.

Consider can.logger being used on an embedded Linux system. A python can.logger ... process is started as a daemon (/etc/init.d/) in boot and killed in shutdown. When the system is restarted, the existing log file on the device and its contents is currently overwritten. This results in a loss of data.

Describe the solution you'd like

Upon executing python can.logger ... the program should check to see if the specified log file exists. If it does exist, then the file should be appended to.

Describe alternatives you've considered

An optional argument could be added (perhaps -a or -w) to give the user the option as to whether an existing file, if found, should be overwritten or appended to.

Additional context

P.S. Feel free to assign this issue to me. I should be around to it by Sunday or Monday.

[j-c-cook]

The can.io.printer.Printer class does contain a boolean option for append:

python-can/can/io/printer.py

Lines 28 to 40 in 0d7f65f

	def __init__(
	self, file: Optional[Union[StringPathLike, TextIO]] = None, append: bool = False
	) -> None:
	"""
	:param file: An optional path-like object or a file-like object to "print"
	to instead of writing to standard out (stdout).
	If this is a file-like object, is has to be opened in text
	write mode, not binary write mode.
	:param append: If set to `True` messages, are appended to the file,
	else the file is truncated
	"""
	mode = "a" if append else "w"
	super().__init__(file, mode=mode)

The function call to Printer in io.logger.Logger does contain the option for *args:

python-can/can/io/logger.py

Line 93 in 0d7f65f

return Logger.message_writers[suffix](file_or_filename, *args, **kwargs)

Due to a really excellent Python API implementation, getting the append option passed down the call stack is not an issue. Passing **options into the logger function call should do the trick.

[j-c-cook]

@zariiii9003 Given the merge of the new feature provided in #1327, could you please consider the next release to be v4.1.0 rather than v4.0.1? If we go by https://semver.org/ for release versions, then the next release would now be considered a MINOR release.

Given a version number MAJOR.MINOR.PATCH, increment the:

1. MAJOR version when you make incompatible API changes,
2. MINOR version when you add functionality in a backwards compatible manner, and
3. PATCH version when you make backwards compatible bug fixes.

I think the easiest way to do this would be to relabel Milestone 4.1.0 to Milestone 4.2.0. Then relabel Milestone 4.0.1 to Milestone 4.1. Then any issues that should be included sooner rather than later can be bumped from Milestone 4.2 to Milestone 4.1.

[zariiii9003]

I don't mind, but i cannot create releases anyway. I will ask @hardbyte once the other bugfixes are reviewed and merged.