Thanks, Darko! That's a handy tip for finding something in code!!! ;)
Got a mac (host on linux - tinker on the mac) and for those that might be looking at this and using Darko's tip on using grep, Apple has evidently compiled grep differently. So after finding other references on the net used this:
grep -r -n --include=*.php "pathtodu" ./
added the ./ at the end to avoid 'grep: warning: recursive search of stdin' and getting hung.
while inside a moodle30 code directory/folder.
Found the same lines ...
So the moodle script does run the OS du only with escapeshellarg and a built in PHP routine for get_size_something.
And I agree, the 'snapshot' could be run via OS cron job - daily snapshot of the code and DB ... could even add an rsync for the data directory. Do that already for a daily backup on some servers.
I was talking about 'convenence' (or for 'lazy true server admins) of having a link right on those screens that tend to deter noobie Moodle Admins.
There's a similar screen when one updates a plugin. And I've had 'noobie' Moodle admins almost refuse to go forward with updating plugins for fear of messing things up (that has happened). Having a 'snapshot' link right there as well would encourage them to 'move forward' (as well as improve the 'damaged trust' issues they have for the code).
Just my two cents, of course ... but will continue and share when I've written up some info on how 2 ... at least with the 'home grown' local/snapshot/ 'semi-plugin' for the 'risk takers'.
The bash shell script I have (and anyone could create), BTW, requires no input by the user (clicker). There's no dialog box for user input. So it doesn't need to have PHP protecting the system by escapeshellarg.
Thanks again, Darko!
'spirit of sharing', Ken