I did as you said..the program calls openssl after rsync to decrypt restored data...
But the patch has serious problems...besides the dest-filter error, testing large amount of data (well, not such large, 70 Mbs), i received this message.. html/lib/perl5db.html 9 [main] rsync 2760 _cygtls::handle_exceptions: Exception: STATUS_ACCESS_V IOLATION 608 [main] rsync 2760 open_stackdumpfile: Dumping stack trace to rsync.exe.s tackdump 1870590 [main] rsync 2760 _cygtls::handle_exceptions: Exception: STATUS_ACCESS_V IOLATION 1909558 [main] rsync 2760 _cygtls::handle_exceptions: Error while dumping state (probably corrupted stack) This patch needs really hard work and lots of testing...reading the list i think i saw something similar rsync error: STATUS_ACCESS_VIOLATION Rob Bosch Thu, 25 Oct 2007 17:56:19 -0700 I don't know if it's the same failure or the same cause... I guess i'll have to figure out another way to rsync and crypt in a efficient way..another idea? By the way thank you very much and sorry for the inconveniences --------------------------------------------------------------------- On Mon, 2008-03-10 at 22:55 +0100, david reinares wrote: > After testing a bit more i discovered that fails when i pass the > command to restore and decrypt with dest-filter (in the client side). > Always the same file, no matter how many times i execute rsync. But > after testing diferent folders, i can't see the conection between the > failed files. html, java, etc, but all of them with more files exactly > like them in the folder but rsync'd and decrypted perfectly. > If i do the same with source-filter (server side) it seems to work ok, > i can restore all files. But that is a problem, because we don't want > to have the files decrypted in the server not even for a second, > appart of the fact that having a big bunch of clients restoring at the > same time with all the hard work of decrypting in the server side > would overload the server. > > > -------------------------------------------------------------------------------------------------------------------------------------------------- > Very good this patch...thank you > > I've been testing this after patching rsync, and works fine to backup...but > > when I'm restoring the crypted data after a while rsync shows > rsync: Failed to close: Bad file descriptor (9) > rsync: Failed dup/close: Bad file descriptor (9) > rsync error: error in IPC code (code 14) at pipe.c(208) [receiver=3.0.0] > > rsync error: error in IPC code (code 14) at pipe.c(195) [receiver=3.0.0] > rsync: connection unexpectedly closed (55 bytes received so far) [generator] > rsync error: error in rsync protocol data stream (code 12) at io.c(600) > > [generat > or=3.0.0] > > It's a bit strange. It restores some files before failing, and they are > perfectly decrypted...i'm using openssl as command I will look into the problem with the patch if I get a chance. One workaround for restoring files would be to rsync the desired files to the target machine without filtering and then decrypt them there (with rsync and --source-filter or just a shell script). Matt
-- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html