Re: Feature Request - Load Throttling

Marc Perkel wrote: down under high load levels. Seems to me that it could be something fairly easy to add to have it check the load levels and back down so as not to slow down the system. As jw indicated, it isn't such a great idea to put that into rsync itself. Instead, use the OS-supplied faci

Re: workaround for HFS+'s case-insensitivity?

Daniel M. Drucker wrote: Short of repartitioning my hard drive and making a UFS partition, is there any workaround anyone has come across? Don't repartition, and certainly don't try MacOSX on UFS. The OS works perfectly from a UFS partition, but the results are less than satisfactory with third

Re: doing an md5sum rsync?

Martin Pool wrote: On 9 Sep 2003 Greger Cronquist <[EMAIL PROTECTED]> wrote: See also unison, http://www.cis.upenn.edu/~bcpierce/unison/ which does exactly this (and synchronizes using the rsync algorithm). Yes, Unison is very cool. I hadn't realized that it detected renames though. xferbycop

Re: Recuperar: binary copies vs ascii copies

Carniado Rodríguez Claudia wrote: Carniado Rodríguez Claudia desea recuperar el mensaje "binary copies vs ascii copies". Claudia, I don't think you can cancel/recall emails sent to a mailing list. That's the nature of the beast. cheers, martin -- To unsubscribe or change options: http://li

Re: rsync OS X to Linux => problem diacritical marks

jw schultz wrote: This isn't an rsync problem. This is an issue of how OSX is handling internationalisation vs. how your linux system and utilities are configured. I don't know how OSX handles it. For Linux take a peek in the locale manpage. From Mac OS X "Jaguar" (10.2) to RH8 using rsync I see

perlrsync (was plain source -> encrypted destination: rsync + gpg)

Hi, I have achieved a reasonable preprocessing of files before pushing them to the remote server (for instance, compressing or encrypting the files) using perlrsync (in the source) and rsync (destination). I tried patching the rsync sources, but it's obviously non-trivial and I am obviously no

Re: [librsync-devel] Re: state of the rsync nation?(revisited 6/2003 from 11/2000)

Donovan Baarda wrote: For the record, librsync version 0.9.6 is _almost_ ready in CVS. A bug has been detected but not isolated yet for large files (2G+). If it's not squashed soon I'm tempted to release anyway with a KNOWN_BUGS that reports this. Donovan, I am just looking around for hints o

Re: Mirroring OS X folders with Rsync

Adam, you don't need to switch to UFS completely. You can create a UFS partition on free HD space, or on a second HD. You can even create a UFS disk image inside a file and mount it. There is a GUI utility (can't remember the name right now) to do it, or plain old CLI utilities to do it as wel

Re: Mirroring OS X folders with Rsync

What filesystem are you using? If you are using HFS or HFS+ I suggest you give UFS a try because it all the filesystem semantics are what unix tools expect. While I haven't seen your specific problem, I am sure there are quite a few situations where rsync and other unix tools will be confused o

Re: compression and encryption

jw schultz wrote: Read the list archives. This has been talked to death. Amen. Most recently, Martin Langhoff has spoken of doing some work on using sender-side filtering that sounds promising. There is also a receiver-side patch out there with the performance issues you mention. I&#x

Re: Some C help patching sender.c (from:plain source -> encrypteddestination: rsync + gpg)

jw schultz wrote: Down to what I am asking help with: I am _not_ a C hacker at all, my strenghts are Perl -- if anywhere at all. So I would appreciate your advise before I shoot myself in the foot. My _advice_ is to miss. Whoa! Hadn't thought of that ;) I have seen Kyle's approach of handling

Some C help patching sender.c (from:plain source -> encrypteddestination: rsync + gpg)

Hi, I am exploring extending Kyle Jones' patch (which implements post-transfer filter in receiver.c) to pre-filter or otherwise pre-process the file before it is sent. Kyle Jones patch can be found here

Re: plain source -> encrypted destination: rsync + gpg

Kyle Jones wrote: Right. I was willing to give up the checksumming for my application. It seems that you could code a --source-filter patch that would - compare the source and destination modtimes - if they differ, then apply the filter to the source file storing the output in a temp file. com

Re: plain source -> encrypted destination: rsync + gpg

jw schultz wrote: Am I on the right track? Help/advise? Is it doable at all? That sounds fairly doable. I'm thinking what you would do is to create a temporary file to match/send and delete it on close. Essentially wrap the applicable open and close ops. I may try something this weekend. Actual

Re: plain source -> encrypted destination: rsync + gpg

I am thinking of running an arbitrary command on the server, when it is Of course, I meant s/server/sender/; m -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

Re: plain source -> encrypted destination: rsync + gpg

jw schultz wrote: Stop thinking client and server. Once the session is initiated there is little difference. Think instead sender and receiver. Good advise. Have to rephrase myself, then ;) As I read the patch, it seems to be running an arbitrary command on the receiver. I am thinking of runni

Re: plain source -> encrypted destination: rsync + gpg

[EMAIL PROTECTED] wrote: The filter run on the client ! Are you sure? I just re-read the patch and it still seems to be at the server. Maybe I don't have the right idea of server/client in my head. Or I am just misreading the patch. How can I tell it's on the server? m -- To unsubscrib

Re: plain source -> encrypted destination: rsync + gpg

[EMAIL PROTECTED] wrote: It seems that the --dest-filter patch of Kyle Jones can help you. Here is a link http://groups.google.com/groups?q=%22--dest-filter%22+group:mailing.unix.rsy nc+group:mailing.unix.rsync&hl=en&lr=&ie=UTF-8&group=mailing.unix.rsync&selm =b6f55s%24256q%241%40FreeBSD.csie.NCTU

Re: plain source -> encrypted destination: rsync + gpg

Yet another thread on the matter -- To unsubscribe or

plain source -> encrypted destination: rsync + gpg

We want to keep a backup or a mirror of your files in a server we don't fully trust. You can have an encrypted FS on a file, and copy the complete FS to the untrusted server, but it is inefficient, and you get no granularity at all. In our case, the remote server runs amanda, and we want to use