Re: should rsync also be called ssync?
On Thu, Mar 01, 2001 at 06:31:49PM +1100, Andrew Tridgell wrote: It would also ease confusion as everybody begins to think "r* means bad security". I think this argument is a little weak. There are 143 commands starting with r on my system. Only 2 or 3 of them suffer from the rsh style security problems. Right, but in particular the network commands that rsync is perceived to be among. I assume the "r" in rsync was derived from the "r" in rsh and probably many other people do too. On Thu, Mar 01, 2001 at 01:16:29PM +1100, Martin Pool wrote: On 28 Feb 2001, Dave Dykstra [EMAIL PROTECTED] wrote: ... I guess this is getting off the track, but I think that is a kind of wierd situation. If you're allowing rhosts login for rsh, why not allow it for ssh? It is allowed but the problem is that it takes a while for people to figure out that they also need to have a "known_hosts" entry for the client machine because only RhostsRSAAuthentication is allowed. Also, the client isn't always setuid-root which is also needed for .rhosts. ... Why not just do it as a shell script? #! /bin/sh rsync -e ssh "$@" The GNU Standards (for what they're worth) deprecate having program behaviour depend on argv[0], and I'm inclined to agree, especially because you're doing to support a program that really should be dead by now. That's an interesting idea that I hadn't thought of for this case. I'm assuming you mean including that shell script in the standard package and not just suggesting that people do this on their own. I'll consider it when I get into it, but I can think of a couple minor disadvantages of doing it as a shell script: 1. It can be tricky to locate another program sometimes. It's not always in the PATH. An absolute path can be used but then the package isn't relocatable without edits and so far the rsync package is. A counter argument of course is that people could just edit the script to relocate it. 2. It's slightly slower on startup. Anybody know GNU's reasons against having program behavior depend on argv[0]? I guess GNU has had a lot of headaches with people want to install things with a "g" prefix or not, that might explain it. - Dave Dykstra
Re: (no subject)
On 1 Mar 2001, "Canteenwala, Adil" [EMAIL PROTECTED] wrote: Hi, Where can I find documentation on following error? "Couldn't initialise builtin random number generator -- exiting." Or can anyone explain why I am getting this error message??? What is the remedy?? This is probably from ssh. Try ssh'ing into the target machine by hand first, or doing rsync -e 'ssh -v' other stuff -- Martin Pool, Human Resource Linuxcare. Inc. +61 2 6262 8990 [EMAIL PROTECTED], http://linuxcare.com.au/ Linuxcare. Putting Open Source to work.
Re: should rsync also be called ssync?
We're having a debate in which some are advocating changing a long-established and respected utility name, with the sole purpose of placating ignorant, inflexible-minded fools. Did anybody notice this? Tim Conway [EMAIL PROTECTED] 303.682.4917 Philips Semiconductor - Colorado TC 1880 Industrial Circle Suite D Longmont, CO 80501
Re: should rsync also be called ssync?
I spoke too harshly anyway. At the start, it looked like just an alias, and I couldn't figure out why the code needed to be changed, when we could have a script called ssync, containing (after the interpreter line) exec rsync $@ . The only reason I could see to put the change into the code would be to change what's seen in the process table, so some idiot who judges programs by their name won't kill it. I personally would rather see spare brain ticks spent on a speeding the construction of file lists. I wish I had the skills to help. Tim Conway [EMAIL PROTECTED] 303.682.4917 Philips Semiconductor - Colorado TC 1880 Industrial Circle Suite D Longmont, CO 80501 [EMAIL PROTECTED] on 03/01/2001 02:56:02 PM To: Tim Conway/LMT/SC/PHILIPS@AMEC cc: [EMAIL PROTECTED]@SMTP Subject:Re: should rsync also be called ssync? Classification: On Thu, Mar 01, 2001 at 01:54:04PM -0600, [EMAIL PROTECTED] wrote: We're having a debate in which some are advocating changing a long-established and respected utility name, with the sole purpose of placating ignorant, inflexible-minded fools. Did anybody notice this? Not changing. Just adding an alias. - Dave
[Module] pysync 1.2
pysync 1.2 -- A Python implementation of the rsync algorithm. This is a demonstration implementation of the rsync algorithm in Python. It is not fast and is not optimised. The primary aim is to provide a simple example implementation of the algorithm for reference, so code clarity is more important than performance. Ideas have been liberaly taken from libhsync, xdelta and rsync. Release 1.2 introduced the new zlib-like API, allowing for incremental calculation of deltas and applying patches. The comments at the top of pysync.py explains it all; # Low level API signature calculation sig=calcsig(oldfile) # Low level API rsync style incremental delta calc from sig and newdata delta=rdeltaobj(sig) # or for xdelta style incremental delta calc from oldfile and newdata # delta=xdeltaobj(oldfile) incdelta=delta.calcdelta(newdata) : incdelta=delta.flush() # Low level API applying incremental delta to oldfile to get newdata patch=patchobj(oldfile) newdata=patch.calcpatch(incdelta) : The rdeltaobj.flush() method supports R_SYNC_FLUSH and R_FINISH flush modes that behave the same as their zlib equivalents. Next on the TODO list is incremental signature calculation, and further cleanups. Eventualy I plan to create a md4sum module and move the rolling checksum stuff into C code. The performance has been marginaly hurt by this new API. Interestingly, the python profiler shows that most of the time is wasted performing string-copies when taking slices from input buffers, not actualy doing the rsync. This suggests that significant performance increases might be achievable by re- arranging things a bit, rather than moving python code into C. I have also added a pysync-test.py script for thorough formal testing of pysync. It generates/reuses random test files that make pysync really work hard, verifying that it behaves as it should. Incidentaly, release 1.2 also fixed a rather embarassing bug introduced in release 0.9's adler32.py that corrupted the rolling checksums, resulting in heaps of missed matches. This bug caused seriously bad performance and very large deltas. URL: http://freshmeat.net/projects/pysync/ Download: ftp://minkirri.apana.org.au/pub/python/pysync/pysync-1.2.tar.bz2 License: LGPL Categories: Encryption/Encoding Donovan Baarda ([EMAIL PROTECTED]) http://sourceforge.net/users/abo/ -- ABO: finger [EMAIL PROTECTED] for more information.
To exclude or include... That is the question.
I'm trying to use rsync to backup user home directories. They all live in /home, but so does some other rubbish which I do not want. The user ids all start with u, so I tried something like this: exclude = * include = u* But this will only allow processing of file and directories that start with u. What I want is for everything below the ublahblah directory to be copied. How to achieve this... simply? Many thanks to those that help.
