Hi Darren, Are you aware that there is already a rdiff-backup FUSE plugin?
http://code.google.com/p/archfs/ Cheers, Anthony > I'm currently working on the early stages of a fuse filesystem for > rdiff-backup repositories. As I look through the rdiff-backup code I > noticed that it is written around the command line interface > (unsurprisingly). As I would like to use the rdiff-backup python > packages directly, rather than forking a subprocess each time the fuse > fs needs data, I wanted to get the developers' thoughts on the API of > rdiff-backup. Are the rdiff-backup packages used by rdiff-backup's > Main.py likely to remain more or less stable, or should I expect a lot > of churn in how they are implemented? > > While tinkering with generating listings (for 'ls') I found it would > be a lot more efficient to be able to do a non-recursive > restore.ListAtTime(). Specifically in > MirrorStruct.get_rorp_iter_from_rf(). For example something like: > > def get_rorp_iter_from_rt(self, rf, recurse=True): > > would do the trick and requires no other changes to rdiff-backup. > Perhaps the recurse option should be available higher up the stack as > well, perhaps in restore.ListAtTime() itself, but the idea is the > same. Would the developers be amenable to such a change? I'm sure I'll > run into several more similar sorts of tweaks that would make the > rdiff-backup packages more usable as a general purpose rdiff-backup > repository access library, and I wanted to get a feel for how likely > it will be for such changes to make it into rdiff-backup proper. > > Thanks, > > -- > Darren Hart _______________________________________________ rdiff-backup-users mailing list at [email protected] http://lists.nongnu.org/mailman/listinfo/rdiff-backup-users Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
