Problems with 0.10.0 on Windows

[Ben Escoto]

--==_Exmh_-794354112P
Content-Type: text/plain; charset=us-ascii

>>>>> "PE" == paul-erik torronen <iso-8859-1>
>>>>> wrote the following on Fri, 20 Sep 2002 09:38:45 +0300

  >> In the future perhaps we need an --exclude-special-files option?
  >> How about sockets, can you back those up?  Symlinks?

  PE> AFAIK no, but then again, those are not important in our case.
    ...
  PE> AFAIK all, including the newest NTFS which is shipped with the
  PE> Windows XP. This is a 'compatibility' feature.

Ok, then I suppose it would be a good idea to have
--exclude-special-files exclude sockets, symlinks, fifos, and device
files.  Then --windows-mode could be short for "--exclude-special-files
--chars-to-quote A-Z: --quoting-char ; --windows-time-format".

  PE> And obfuscates the files quite effectively.

Yes, both schemes obfuscate the filenames, but at least no data should
be lost (except the special files), and the above would be easy for me
to add.

  PE> Just a thought, why not support encapsulation on the remote-end
  PE> as an option? This would retain the local access-parameters of
  PE> the file and would also solve the abovementioned
  PE> case-sensitivity problem (and filename length, if used on some
  PE> seriously crippled or outdated system).

  PE> For example in our case the client (linux) sends the initial
  PE> files in a tar-ball which the server (windows) then uses as a
  PE> base to calculate whether the files have changed since.

  PE> In princip use some suitable archiving system (why reinvent the
  PE> wheel?)  and create a 'virtual filesystem' on the server which
  PE> supports the features of the remote client filesystem.

There has been some discussion of this idea for the rsync2 project.  I
am hoping something comes out of that project, and some future version
of rdiff-backup can use their framework.

    You've noticed, as they did, that there can be a conflict between
preserving data and mirroring.  For instance, when backing up to a
file system with only short names, I can choose to write everything in
a big tarball (only preserve data, no mirroring at all), or to chop
off any long filenames (looks a lot like a mirror, but lose data).

    rdiff-backup conflates these two, so probably is only useful when
a mirror does preserve the relevant data.  Otherwise another tool may
be better (cf your next message).

    There is one complication worth mentioning though:  rdiff-backup
keeps changing the 'full' archive, and produces reverse increments
going back in time.  It can do this because it has random read/write
access to the mirror.  Any 'virtual filesystem' suitable for use would
have to solve some of the problems of a real filesystem like random
access, allocating space, defragmenting, how to handle a crash in the
middle of writing data, how to keep some operations atomic, preventing
globals corruption, error-recovery, etc.  Duplicity just uses tar, but
it uses the standard full+forward increment scheme.  rdiff-backup can
do it the other way just because the native file system solves a lot
of problems.

  PE> BTW. the fifo-patch seems to work fine, but now the rdiff-backup
  PE> seems to doze off from time to time and wakes up at keyboard
  PE> acitivity. I ran it (with -v7) of the cmd-console and noticed
  PE> that it had stopped at some large file (~600 MB). Left it for
  PE> the night and it was still in the same state when I came back in
  PE> the morning. The task manager showed no action until I hit the
  PE> enter-key in the console window. The program resumed after that
  PE> just as nothing had happened. Weird...

Yes, very strange..  Maybe your computer was asleep or something and
your keyboard input woke it up?  Well that's all I can think of.


-- 
Ben Escoto

--==_Exmh_-794354112P
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Exmh version 2.5 01/15/2001

iD8DBQE9i1N4+owuOvknOnURAoInAJ9HbMs0yZy46iIvtuEtX+pB9r/UBgCggI6W
BVjfZ2aJqgzfMqpGKdBW+NA=
=skEG
-----END PGP SIGNATURE-----

--==_Exmh_-794354112P--