On 7/29/06, dean gaudet <[EMAIL PROTECTED]> wrote:
On Sat, 29 Jul 2006, Chris Connett wrote:> On 7/24/06, dean gaudet <[EMAIL PROTECTED]> wrote: > > it's not supported yet... patches welcome. > > OK, I've written a simple patch to use the tempfile module out of the > standard library. I've written it to maintain compatibility with > Python 2.2, which appears to be this project's compatibility target. > I had to use the module in a slightly unorthodox manner, to keep the > interface the same. Patch is against latest CVS. Comments welcome. thanks... but i'm not sure this is going to work... note the comment for the function you modified: def new_in_dir(dir_rp): """Return new temp rpath in directory dir_rp""" i'm pretty sure that function is called in situations where rdiff-backup needs a temp file on the same filesystem as a particular directory -- so that it can be renamed. TempFile.new also uses TempFile.new_in_dir... and look at the callers: % grep TempFile.new *.py Rdiff.py: tf = TempFile.new(rp) backup.py: tf = TempFile.new(mirror_rp) backup.py: self.dir_replacement = TempFile.new(base_rp) backup.py: tf = TempFile.new(mirror_rp) fs_abilities.py: subdir = TempFile.new_in_dir(rbdir) journal.py: entry_rp = TempFile.new_in_dir(journal_dir_rp) regress.py: temprp = TempFile.new_in_dir(Globals.rbdir) regress.py: tf = TempFile.new(rf.mirror_rp) restore.py: tf = TempFile.new(rp) restore.py: self.dir_replacement = TempFile.new(base_rp) for your needs w.r.t. restore you probably want to audit the uses in restore.py and see if the can be changed to use a non-local inode. i suspect you're going to have some troubles with fs_abilities... although i don't really think it should need to know the mirror fs abilities when it's doing a restore... because it should be extracting everything it needs from the metadata. but i'm not 100% hopeful that will work properly. btw when testing this patch you probably want to test a bunch of variations: - local->local; local->remote; remote->local - backup, restore, regress - TMPDIR pointing to different fs (for maximum breakage -- no need to point it at the same fs... if everything works on a different fs we're probably fine) note that if you want to script this sort of testing you can test a "remote" end without using ssh... this is effectively remote from rdiff-backup's point of view: rdiff-backup --remote-schema '%s' 'rdiff-backup --server'::src dst that'll just open up a pipe to another rdiff-backup and it's equivalent to running it over ssh for most testing purposes. thanks for looking at this...
Thanks for your comments. Jumping into a new code base, I was pretty sure I wouldn't get it right my first shot. I looked for the callers when writing this, but I took the assert to mean temp files should always be local, which apparently isn't the case. But will the test be accurate without actually using a separate machine? Temp filenames generated by one process will still happen to be accessible by the other, where in a true remote environment that may not be so. I'll assume for safety that I should use two real machines unless I hear otherwise. -- Chris Connett _______________________________________________ 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
