Most good SCM systems (Subversion, Perforce, et al) will keep this kind of information automagically and then it's just a matter of judicious parsing of the output from svn log or the like to produce a report. And you really should be using some form of SCM anyhow, so why bother with the record-keeping yourself?
And condolences on the SOX thing; I've felt and continue to feel said pain. %/
| [reply] |
| [reply] |
Without getting into specific implementation details; personally, I'd store a Digest::SHA1 hash along with a file size and date stamp in a file or database table. There is a risk of collisions, but it's probably pretty small if you also compare the file size.
To make sure it worked right even when there were no databases to connect to, I'd probably use DB_File or Storable. Even DBD::SQLite would be an excellent choice for that. I think it's largely a matter of preference, but if you like the look of Storable.pm, be sure to think about splitting it up by month and/or directory. Otherwise, reparsing that file into memory every time the program runs could get expensive.
Then, when you need to generate file change reports, you can just work off the simple database and you're done!
| [reply] |
In the past, I've considered installing tripwire or aide (see google) so that I could prove that a sys admin had modified something on a production system without proper notification. These tools might be used to handle SOX requirements.
| [reply] |