einsteinx2
commented
6 years ago Since log files can be very long or very short as they are created one per session (longer on macOS, shorted on iOS usually, but can vary), I think it's best not to just keep a certain number of logs but rather keep a certain size of logs. That size should mainly be determined by how large the zip file will be if all logs are zipped (for when we send feedback emails). Too large and feedback emails will take forever to send. Too small, and we lose valuable data in helping a user with a problem.
I did a rough estimate by seeing how my log files compressed and saw that the zip file created was about 15% the size of the original log files, so I'll use that number for my calculations.
I think a reasonable maximum upload size is about 500KB, which means we can keep about 3.5MB of raw log files at any time. That should be more than enough to debug most any issue.
I'll purge old log files on app launch when we create the new one. Just in case a user has a ridiculously long uptime, I'll add some logic to prevent the most recent log files from being removed even if they go over the 3.5MB limit. So the logic will be remove all log files, starting from the oldest until we are under 3MB (to allow for the current log file), but will never remove the most recent 3 log files even if it means we're over (presumably if they have super long log files they're on a desktop/laptop and so have faster upload anyway and can upload a larger zip file).
Right now we never purge old log files. This is a problem for obvious reasons. This is simple to do, the framework we use supports it now (it didn't before).