Re: [rdiff-backup-users] rdiff-backup restore from read-only file system

[Chris Connett]

On 7/29/06, dean gaudet <address@hidden> wrote:
> On Sat, 29 Jul 2006, Chris Connett wrote:
>
> > On 7/24/06, dean gaudet <address@hidden> 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