Re: Audit trail of file changes

On Fri, 22 May 2009, rob@xxxxxxxxx wrote:

Journals do need careful management. If you are truly only ever going to
journal this one file and no others, or, if you do start journalling other
files then you will have NO concerns about commitment control, etc, then
you may wish to journal just this one file to it's own journal. This will
allow you to customize the retention of that journal. However if you want
to start using commitment control and this file may be part of a
commitment boundary then you may will probably have to have all the files
in said boundary in the same journal.

I honestly don't see us using commitment control. I think that would involve substantial rewriting of the applications. All we need is a way to show before and after contents of this single file in a way that is provably correct.

Guess what our biggest library on our system is?

This does concern me. At first I thought they only wanted to keep the trail for a period of about a month. Now I found out they want to keep it indefinitely. I noticed that the journal holds a lot more than just updates, adds, and deletes; it also tracks every open, close, and backup. I don't really need that second class of information. Is there a way to either purge unwanted data or only log updates?

Another thing that has me a little confused is that the record length of the file I'm journaling is 1088 but the field in the journal that I believe holds the changed data is only 100. How can it possibly hold the before and after images when the field is so much smaller that the record?

James Rich

if you want to understand why that is, there are many good books on
the design of operating systems. please pass them along to redmond
when you're done reading them :)
- Paul Davis on ardour-dev