Does System.Log work in 2019r1.1 on MacOS? I can’t seem to find anything in Console.app. Is it a security thing in Catalina maybe?
Wondering what the best way is for my program to log in a way that slows down the program as little as possible and will send logging data as long as possible in the case of a crash. I feel like opening a text file, appending, closing might be slow as the data I’d like to log could be flying in at many per ms. I’d also not like for the program to crash in the middle of writing the log file before it gets a chance to close and leaving part of the messages behind.
Don’t do this manually. textoutputstream.append leaks on Catalina, eventually filling up the allotted amount of files an application is allowed “open”, and thus preventing your application from opening or saving any more files.
There’s certainly uses for it. In an ideal world, Apple would let our apps dig into the system and to recall any data our apps has written there. However for “Security” Sandboxed apps are prohibited from accessing the log data, not to mention that it is incredibly slow.
I filed a feature request with Apple to allow this, but so far no response and I guess like any FR I make for security, it’ll get ignored or shot down.
If you’re outside of the App Store, it’s totally possible for an application to do a log dump of everything the Unified Apple Logs have collected on it. I may even see if I can utilize this in a future AW version.
I don’t use append. Just flush. If flush is used, the data seems to be written to the file, and even if it doesn’t get closed it’s still seems to be fine. I’ve looked at the file during the middle of the program (before it’s closed) and it’s all valid. My guess is that a text file is maybe tolerant of not being closed?
Not sure if you were replying to my comment? If so, my reference to “tolerance” was that it seems that closing the file isn’t necessary for it to be valid and readable. As opposed to some other binary files that if they are not closed properly, they end up corrupted. (I’ve seen many music files (esp. mp3) have this issue).
I do close the file at the end of program, but it’s nice to know that if the program crashes for some reason, the file is still readable. Maybe all the open/append/write/close steps are not really necessary for a simple text-based log file?
text files can be forgiving this way
binary files can be as well - just that usually if they are incompletely written then the software that reads these files has issues because the file is incomplete
I would expect that as long as you flush the output stream (text or binary) that you should be pretty safe and the data will be “safe” and readable
Note that Apples system log facility caches things and does not write everything to disk
The system stores all messages in memory initially, and it writes messages with more severe log levels to disk.
This may also be what you’re not finding all your log messages unless console is running and filtering for those messages (Yet another case of Apple trying to be helpful and making this more a pain in the ass in the process)
What I cant say is whether Xojo’s System.debuglog and System.log call into this newer os_log api or use the older one. That may play into it as well
This may be useful as well on macOS as you can, on a per application basis, alter the logging behaviour