With this approach all files would have to be listed in the include/exclude lists - i.e. no wild cards....
S >From: Manfred Schuler <[EMAIL PROTECTED]> >To: Charles Steinkuehler <[EMAIL PROTECTED]> >CC: [EMAIL PROTECTED] >Subject: Re: [Leaf-user] a thought about modified file backups >Date: Fri, 04 Jan 2002 04:57:45 +0100 > >Maybe you can use this procedure: > >build the include and exclude list as you do it now >then check the date of each file on the includelist >if the date is the same as on the CD then add this file to the exclude >list > >Charles Steinkuehler schrieb: > > > > > 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 > >-- >Manfred Schuler >E_Mail: mailto:[EMAIL PROTECTED] > >_______________________________________________ >Leaf-user mailing list >[EMAIL PROTECTED] >https://lists.sourceforge.net/lists/listinfo/leaf-user _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. _______________________________________________ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
