On Wed, 2004-09-15 at 14:47 -0400, Erik LaBianca wrote: > > > I think the place to tackle this stuff first for both the home directory > and system configuration aspects is with regard to choosing files to > backup intelligently. Someone pointed out that their rpm folder is > monstrous. Mine is too, as are bunches of other folders floating through > my home directory and system. Perhaps a simple standardized home > directory layout is in order. > > For instance: > One might have a ~/tmp into which ~/rpm/BUILD and other junk > accumulators would be linked. It would have a no-backup policy. Then > perhaps a ~/static or some such where one could put their music files, > movie rips, ~/rpm/SRPMS, random tarball downloads, fedora install tree > mirrors, or whatever else they might be hauling around that never > changes. Such a folder could (and should) have a different (lower > priority, server-wins?) sync policy than, for instance ~/Maildir (high > priority, last update wins?). I don't think this should be policy pushed from RedHat/Fedora. It seems to be much more of an organizational policy. As long as the user interface presents a reasonable interface for exclusions (I'm not sure that there would be an inclusion option...), with the default 'sync all' concept, it should work fine. Having priority on directories would certainly be interesting, though may have to be tackled at the next pass. It seems to me that rsync makes a great candidate for this purpose, though there are some limitations (unless I'm just not aware of certain command flags): 1 - being in a library would probably be much nicer for this task, rather than spawning a process and trying to parse it's output 2 - Being a seperate process, there isn't the same ability to start/stop/pause from a user interface. 3 - Does not provide easily machine parseable output for a gui to provide status information There is a librsync project at sourceforge (http://librsync.sf.net) though it is listed as not wire compatible with the v2 rsync protocol. It may be sufficient for this purpose however. -- David Hollis <dhollis@xxxxxxxxxxxxxx>
