Stuart Jansen wrote: > On Mon, 2007-03-26 at 13:01 -0600, Michael Lovell wrote: > >> I have an interesting situation with a backup system. The system >> determines what files have changed for the incremental backups by >> looking at the ctime on the file. No big deal there. Unfortunately, >> there is something that will change the ctime on all of the files on a >> 1.4TB volume which causes the backup system to backup the whole volume >> every week or two. Do any of you know an easy way to monitor for a >> change in ctime and be able to report what process changed it? The >> volume that this is happening with is running on a server with Novell >> OES and samba 3.0.20 that has both Windows and Mac Clients connecting to >> it. The weird thing is that this one volume is the only one it is >> happening to this one volume. The others on the server don't have this >> problem. Any thoughts on this? Thanks for the help in advance. >> Mike Lovell >> > > I'll leave someone else to discover a neat auditd or selinux hack to > accomplish this. Instead, I'll point out a common misconception about > ctime: ctime records when the inode of a file was modified. For example, > changing the owner, permissions, and a slew of other metadata results in > a ctime change. I seriously doubt that's the the sort criteria you want > to use to govern backups. > I agree with you that ctime shouldn't be used for this but unfortunately the backup software wont let me change this. Plus it is useful sometime to backup if permissions changed (while that is a rare need). I did just discover what was doing it though. One of the users had Windows Desktop Search index the whole volume. And go figure that the indexing process changes the ctime on the files. So random FYI in the future, if you run a file server with large amount of data that is backed up by ctime, you don't want users running Windows Desktop Search on it. Oh, and I checked Google Desktop while I was at it. Google Desktop does not show this behavior. I know this is mostly useless info but someone might find it useful later.
Mike Lovell /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
