rdiff-backup-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [rdiff-backup-users] a windows release and some questions


From: Ben Escoto
Subject: Re: [rdiff-backup-users] a windows release and some questions
Date: Sun, 8 Feb 2004 14:08:09 -0800

>>>>> "David Kempe" <address@hidden>
>>>>> wrote the following on Mon, 2 Feb 2004 17:16:46 +1100

> I also have a few problems with rdiff-backup on windows that I have found.
> 1) for some reason the metadata file is not being written to the destination
> (linux).
> so backing up from win32 -> linux rdiff-backup complains about no metadata
> file on the destination existing.
> This means the backup parses the files each time and attempts to upload the
> metadata on every single backup.
> The metadata file IS being created on the destination, just when
> rdiff-backup runs on windows, it can't detect it for some reason. I can send
> the mirror_metadata file if needed.
> Also this means when running the new --compare option it gives this error:
> 
> Warning, metadata file not found.
> Metadata will be read from filesystem.
> Fatal Error: Mirror metadata not found
> Cleaning up

Not sure I understand the problem.  The metadata file is getting
created but not "written"?  So it's empty or something?  What is the
file name?  It shouldn't be quoted if it is on the linux side.

> 2) We have made great progress on the rdiff-backup web interface for
> restoring.
> However it would be good if we could direct rdiff-backup to restore a file
> to stdout - that way we could pipe files back to users instead of using a
> temp directory. How much work would it be to add this feature - one of my
> guys is having a bash now, but doens't know python that well, so its
> probably not going to be a great effort :-) Ben, if you could add restore to
> standard out as a feature on linux at least, we will try and see if we can
> get the company sponsoring the devel of the web interface to open source
> some of it at least.

This would actually be a pain to add because rdiff-backup deals with
files which have filenames, metadata, etc.  Most of the functions deal
at that level of abstraction.

So instead of restoring $RESTORE_IN to stdout, why not write a script
that goes like this:

rdiff-backup -r xxx $RESTORE_IN $TEMP
cat $TEMP
rm $TEMP

There may have to be a temp directory, but the users don't have to
know about that.  I guess the problem is temp space?

> 3)

Will keep this message unread and get back to 3 in a bit hopefully.


-- 
Ben Escoto

Attachment: pgptGr6y0r1JH.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]