Compress log backup files by gzip

[brvphoenix]

Some operations (such as updating RSS schedulely) will make qbittorrent generate a lot of messages. But the qbittorrent will delete old backups only at startup previously. If qbittorrent is running for a long time, log backups will pile up over time.

The main changes in this PR are:

1. Delete obsolete backups when a new backup is generated (previously only at startup). The backups will also be sorted.
2. Allow to compress the log backups by gzip (disabled by default).

84143d487031282669c5a40eb3022747c6ff030c is a little hacking way to implement log compression with streams. I hesitate to add this because I find that the max allowed log file size is 1000MiB.

[glassez]

I don't actually approve of the first commit (at least in its current form). It creates a cross dependencies between Application and FileLogger, which clearly cannot be seen as an improvement from a code structure perspective.

[brvphoenix]

I don't actually approve of the first commit (at least in its current form). It creates a cross dependencies between Application and FileLogger, which clearly cannot be seen as an improvement from a code structure perspective.

I'm not skilled in C++, so please forgive me for asking some ridiculous questions. Can I avoid cross dependencies if using the application interface class? Do you have any suggestions for this, keeping the original form, using a singleton or any other way?

[glassez]

Can I avoid cross dependencies if using the application interface class? Do you have any suggestions for this, keeping the original form, using a singleton or any other way?

I believe the easiest thing for all of us would be to revert this commit.

[glassez]

@brvphoenix
Isn't Read files by QDataStream a separate thing? I would strongly recommend to extract it into separate PR with explanation about its goals.
Also I would split "compressing" and "sorting" work unless they are really too interlinked.

[glassez]

@brvphoenix
I don't have time to review it all at once. I can either do it little by little, leaving some comments individually, or (if you don't like it that way) wait until I can review it in its entirety.

[brvphoenix]

@brvphoenix I don't have time to review it all at once. I can either do it little by little, leaving some comments individually, or (if you don't like it that way) wait until I can review it in its entirety.

I'm OK with that ;).

[glassez]

@brvphoenix
Finally I found time to complete this review. I have a lot of comments about coding style, etc. But this is not the most important thing, it can be easily fixed.
I have a couple of more significant claims that I would really like to be resolved before it is approved:

1. It would be better to unify the naming of backup files in such a way that the name of the compressed file differs only by adding a .gz extension to the name of the corresponding uncompressed one.
2. I really don't like all this hassle with "sorting" backup files (and in fact, it's renaming a lot of files). It would be better for the backup file to remain untouched after its creation (up to its deletion, if configured). We could use the timestamp as a unique component of the file name.

[Chocobo1]

Generally approved (without regarding the code)

[github-actions]

This PR is stale because it has been 60 days with no activity. This PR will be automatically closed within 7 days if there is no further activity.

[github-actions]

This PR is stale because it has been 60 days with no activity. This PR will be automatically closed within 7 days if there is no further activity.

[luzpaz]

Any traction here ?

[github-actions]

This PR is stale because it has been 60 days with no activity. This PR will be automatically closed within 7 days if there is no further activity.

[github-actions]

This PR was closed because it has been stalled for some time with no activity.