On Mon, Dec 29, 2008 at 04:53:04AM -0800, Craig Barratt wrote: > > BTW: Why would that ease support for rsync 3.x? (Just curious.) > > Instead of updating File::RsyncP to rsync 3.x protocol, the idea > would be to use native rsync on both sides of the connection, > and the BackupPC trickery would be hidden behind FUSE.
Ah, I see. That's a rather tempting design. I'd take a look at the file system operations rsync performs before implementing that. I remember that it always creates a new temporary file beside the one it is transferring. You'd need some kind of copy-on-write (which you'll need anyway for a writable FUSE) for in-place replacement. > It's just an idea at this point. The rsync protocol isn't > documented; File::RsyncP was developed by carefully reading the > rsync source. It's certainly possible to update File::RsyncP for > rsync 3.x, but the development and testing effort is relatively > high. Two benefits of using native rsync on the server side are > that a fuller set of command-line options could be used, and the > robustness would be better. One drawback is the rsync checksum > caching wouldn't work with FUSE. While it's tempting, you lose a lot of control (and therefore optimization opportunities) by letting native rsync do all the work and hiding BackupPC behind a file system layer which knows nothing of differential transfers, pooling etc... of course, a writable FUSE view would open a lot more usage scenarios like, for example, providing some "just drop your files here for backup" space in the network. Tino. -- "What we nourish flourishes." - "Was wir nähren erblüht." www.lichtkreis-chemnitz.de www.craniosacralzentrum.de ------------------------------------------------------------------------------ _______________________________________________ BackupPC-users mailing list BackupPC-users@lists.sourceforge.net List: https://lists.sourceforge.net/lists/listinfo/backuppc-users Wiki: http://backuppc.wiki.sourceforge.net Project: http://backuppc.sourceforge.net/
