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
