Problems with 0.10.0 on Windows
Fri, 20 Sep 2002 09:57:30 -0700
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
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
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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Exmh version 2.5 01/15/2001
-----END PGP SIGNATURE-----