> a late night thought: > > why not intercept the write() system call? if the write is to a file on > the filesystem, keep track of its path in some kernel data structure. > better yet, generate a /proc file with the pathnames of all filesystem > files that were modified by write(). > > the backup program would then read from this file and pop off the > pathnames as they were backed up. this would be implemented as a kernel > module.
Hmm...not exactly the first thing that would have occured to me, but it's definately possible. This approach, however, shares the same problem as most of the other schemes to keep track of modified files (like building a list of timestamps/md5 sums or similar): What happens the second time you backup a package? If you only backup files modified in the current session, you're probably going to overwrite (and loose) the files you modified earlier. Let's say, for instance, you just downloaded the latest release, and you modified network.conf so your firewall works with your static IP. You do a modified files backup of etc and everythings great. Next week, however, you need to edit hosts.allow so you can access ssh from your office...what happens when you do a modified backup of etc this time? You need BOTH the modified network.conf and the new hosts.allow... There are ways around this (like generating a "master" file list for each package, with date-stamps or md5 sums that never gets modified), but things rapidly get ugly. - How do you handle directories, for instance (remember, the file list for etc doesn't include each and every file, it's basically just /etc). - How do you support legacy packages that don't include a master list of files? - What if you find a package in more than one place (possible with the new backup scripts) I think the long-term solution to this is a package format that's designed to build a complete filesystem from unmodified "core" packages and configuration data. I've headed towards this with my modifications of the *.lrp packageing system, and David has taken some similar steps. See some of the recent threads on the leaf-developer list for anyone truly interested. Any/all thoughts on this welcome...especially crafty extensions to the current packaging format! Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) _______________________________________________ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
