Couldn’t find anything on this topic, but ran into an issue with the Txt.log file that’s created automatically by VCV rack.
I left my patch open for a while (a week at least) in the background, running but muted in the mixer. Not intentional, just forgot to close it and didn’t use the computer for other things during those days at all.
When I came back to my computer realized that my hard drive with the windows installation was 100% full.
Took a look and the Log.txt file was taking up 750 GB of space! Completely filled up my smaller drive that the OS is located on.
I get it was a mistake to leave it running, but surely there should be a cap on the log file size, as a failsafe for this kind of situation?
It sounds like some plugin is logging too much stuff. Any idea where all that log noise is coming from? If it were my plugin, I’d want to know so I could fix it! I know you can’t reasonably open a 750 GB file, but can you use a command line utility like tail to display the last 100 lines of the file or so, and post that here?
[EDIT] Or better yet, run that same patch again for a few minutes to create a new log file (but much smaller), then upload that to this thread?
Can you provide a snipped of the log file that shows some of the messages logged? That will help me determine, which plugin is potentially spamming the log file. Thanks.
If the VCV Rack developers decide to support a limited log size, I have a suggestion. In my paid C#/.NET work we use Log4Net as our logging provider. We configure it to work this way: log up to 10 MB, then close the file, rename log.txt to log1.txt, rename any log1.txt to log2.txt, up to a maximum of the most recent 8 files (or however many you want to keep).
We do the same bucket brigade thing every time we start up our program as we do when the file hits its size target. So you always have the most recent 8 logs, none of which are much larger than 10 MB (going a few extra bytes over, to flush the current log line, is fine). This means you can never have more than 80 MB of log, and you always have the most recently logged stuff in case something goes wrong.
This could also help VCV Rack support and plugin developers. There have been a couple of times where I have a crash, then I get a brain fart and run VCV Rack again and lose the log with the stack trace I needed. With this change, you can go look at log1.txt and you still have the precious stack trace.
One thing I have done over the years with log files is to decrease the frequency at which the log file writes the longer the program runs. Many years ago I was developing interactive IBM mainframe job submission and management from a PC via LTERM and dynamic JCL virtual card deck creation. IBM had a convenient job status request but no one told me that our company charged the division member who submitted the request $0.25 per time. Do that a few thousand times and it gets peoples attention!
)