@csmann Thanks for your pull request! You have indeed found an issue that slipped through the cracks.

I'd like to propose an alternate solution and see if you have any feedback. Instead of modifying LXRotatingFileEndpoint, I'd like to consider localizing the changes to just LXFileEndpoint. In specific, a line if !shouldAppend { self.resetCurrentFile() } could be added to the File Endpoint's initializer, right after the super.init call. This may not be the most efficient solution, but it has the benefit of fixing the bug without changing the Rotating File Endpoint, and initialization only happens once anyway.

I'm suggesting an alternate solution because the modifications made to LXRotatingFileEndpoint in your pull request change the behavior of LXRotatingFileEndpoint (while also fixing LXFileEndpoint's bug). The Rotating File Endpoint was not meant to present a choice regarding its "append" behavior; it does not quite make sense to do so. The log files for this endpoint must be truncated upon rotation because the rotation condition is based on the size of the log file. If the files did not truncate, the endpoint would break after eventually filling all of the files in its set.

This is also true, to a lesser extent, for LXDatedFileEndpoint, which also inherits from LXRotatingFileEndpoint. Although this change wouldn't break the Dated File Endpoint, it would again changes its intended behavior.

I welcome any thoughts! Again, thanks for your work here.

@justinpawela Thanks for the feedback. After a further review of the code, I would like to propose taking your suggestion one step further. I see now that LXRotatingFileEndpoint should not append by default and LXFileEndpoint would be a better place to define shouldAppend. However, it may be cleaner if LXRotatingFileEndpoint inherited from LXFileEndpoint instead of the other way around as rotation is a specialization of a file endpoint. shouldAppend could be included in the LXFileEndpoint initializer but excluded from the LXRotatingFileEndpoint initializer, passing in a default value to super. That way LXFileEndpoint would not need to override rotateToFileBeforeWritingDataWithLength. This would allow LXFileEndpoint to support a custom shouldAppend value while all other inherited types could pass in default values. Please let me know what you think.

@csmann I completely agree that the standard File Endpoint could make the best base-class, with Rotating and Dated File Endpoints inheriting from it. File Endpoint is supposed to be the simplest case. In fact, that was the original intent and there were many iterations in which that was the case.

I worked at that for a while but could never get it all structured in a way that felt clean and concise. There was always either some DRY violation or some convoluted workaround required to get it to fit together. In the end, making the File Endpoint a special subtype of the Rotating Endpoint -- one that just never rotates -- was the most satisfactory way I could figure to build it.

Honestly, I'm not totally in love with the way the File Endpoints are structured. My biggest complaint is that the Endpoints don't actually attempt to open their log files until the first log entry gets written, meaning a developer actually doesn't know if they can log until they try it. I'd much rather have it fail at initialization time. But the current structure is a result of me trying to avoid DRY violations by moving code out of init and into methods like currentURL, nextIndex, and nextURL, which forced me to make some variables that use those methods (like currentIndex and currentFile) lazy, which of course made file opening itself lazy. All of this affected which file endpoint type needed to be the base class.

Anyway, I won't take up your time with tales of my frustrations. In the short term, I am considering implementing my suggestion from above, only because it is basically a one-liner fix that doesn't rock the boat, and it also doesn't block a larger refactoring effort. I agree that a refactoring could lead to a cleaner solution, but I don't have time at the moment to dig in and refactor the File Endpoints. If you were interested in attempting that (now or in the future), or even if you just wanted to open an issue detailing your thoughts on a better structure, it would certainly be welcomed. Either way, I really appreciate you reporting the bug and putting work and thought into the best solution!

Please let me know if you have further thoughts.

@justinpawela - As your original suggestion seems the simplest fix in the short term I will close my pull request. If I have a chance I will take a look at refactoring the inheritance as discussed, or at the very least create an issue for tracking.

Fixed by 4de48be