killing replayd to force a re-read of plist file

[jaredh159]

Hi there. First, a HUGE thanks for this project, and all the research you've done. This issue is hitting our app, and all the knowledge you've gained and shared has been invaluable. If you had a button to donate, I'd send you a donation.

Anyway, I've been doing a lot of testing of manipulating the ScreenCaptureApprovals.plist file, and realized something you may already know, but was not apparent to me. If I alter the plist file on disk, and then do something (like take a screenshot) which would cause the replayd daemon to have to decide whether it should nag or warn the user, it wasn't seeming to respect the future dates I put in the file. After a lot of trial and error I came to the realization that replayd was using an in-memory representation of the plist file to decide what to do, and then updating the file if it needed to bump or alter some value, so my filesystem changes weren't having any effect.

When i finally realized that, I theorized that killing the daemon would cause it to re-read the plist configuration, and after testing it, it seems to do just that. So basically if you do pkill -9 replayd then the system restarts the daemon, and it immediately picks up the modified dates and values from disk. I suspect that waking from sleep might trigger a re-read as well (and certainly a system restart would, i imagine), so this may not be a huge issue for long-running processes waiting for 30 days to expire, but it was a really valuable thing for me to realize, and I wanted to share.

this isn't really an issue but since you didn't have discussions enabled, i put it here. feel free to close. thanks again!