similar to: rsync digest, Vol 1 #797 - 4 msgs

Whoops, I apologize for the off topic e-nail. I meant to write a reply but I mixed up my messages to the various listservers I'm subscribed to. I'll remember to check my address next time. I've found a new way to run Rsync, it works pretty well, and involves a disk image mounted on a server that's created with Disk Copy. It serves our purpose pretty well for what we're doing

In order to do rsync over ssh without providing a password, you must be able to ssh without a password. The --password-file= option is to provide a password for a rsyncd server (run as rsync --daemon) password. rsync cannot provide a password to an external transport like ssh or rsh. You will find that if you do "ssh -l wl 192.1.4.231 uname -a", for instance, it will ask for a

Wang: I take it you mean that your mail bounced. Your domain is probably in the RBL or something. The commandline you give is an attempt to contact a rsyncd server. That means that the server you're contacting would have /etc/rsyncd.conf, and either an appropriate entry in /etc/services and /etc/inetd.conf, or would be started manually with "rsync --daemon". I'm guessing

> If you have a set of files that are "common" to each side but for whatever reason the content of which you want to keep separate and "localized" then look into using --include and --exclude rules or perhaps an exclusion file. The syntax always gets me > and it might take a couple of tries to get the right sequence of element inclusions. Rene > --__--__-- >

On Fri, 19 Jul 2002, Dan Stromberg wrote: > Many apologies. If we update on the nfs server, as we've intended all > along, we should have no .nfs* files. Well, here's one thing that could make them, even if they're being created only directly, not over NFS. I'm watching the directory you're syncing into. I open the file while it's still there. You delete it, and

Sonu: I'm giving the whole history to the rsync list. If the tests i subscribed passed, yet you get that error, it's more in depth than i can go into. You've got 1 hour, let's hope somebody immediately recognizes the problem. I've got some ideas, but no time to explore any more for you. Gentlemen: does anybody see a quick resolution for Sonu? Looks like he's

see a copy of your rsyncd.conf? Tim Conway tim.conway@philips.com 303.682.4917 Philips Semiconductor - Longmont TC 1880 Industrial Circle, Suite D Longmont, CO 80501 Available via SameTime Connect within Philips, n9hmg on AIM perl -e 'print pack(nnnnnnnnnnnn, 19061,29556,8289,28271,29800,25970,8304,25970,27680,26721,25451,25970), ".\n" ' "There are some who call me....

it's in syscall.c, not generator.c You'll have to save the status of the lstat, modify the mode in st, and return the lstat status. I don't know how to do it, though. #if SUPPORT_LINKS int do_lstat(const char *fname, STRUCT_STAT *st) { #if HAVE_OFF64_T return lstat64(fname, st); #else return lstat(fname, st); #endif } #endif Tim Conway tim.conway@philips.com

The "-a" option (the "--links", "--perms", "--devices", and "--times" options are redundant, as they, as well as "--owner", "--group", and "--recursive" are implied by "-a" )does dictate that permissions on files being sent be brought over from the source. Are all files losing permissions, or only files

I should have specified what i was replying to. This section seemed to be in reference to what I had experienced before. " > Well, I'm stumped too. (Although I thought I'd read that the > default timeout was not infinite when not otherwise specified, > but I've got so much going on right now that I could easily be > confused on that one!) > " Tim Conway

I keep getting these smarmy sermons from somebody's mail account. I include my response to it below, though from its message, it probably won't be read. Tim Conway tim.conway@philips.com 303.682.4917 Philips Semiconductor - Longmont TC 1880 Industrial Circle, Suite D Longmont, CO 80501 Available via SameTime Connect within Philips, n9hmg on AIM perl -e 'print pack(nnnnnnnnnnnn,

Gouri: close. Try "Ssh-keygen -p -P ''". You might argue that ssh should guess that -P imlplies -p, but that's an issue for your ssh maintainer. Also: you don't ordinarily distribute the private key. You need the PUBLIC key in $HOME/.ssh/authorized_keys on any system you want to access with the private key. Maybe i'm seing your application backward, and you

The way gnutar "preserves" atime is by noting it before the read, and setting it back after the read, thus wiping out a legitimate setting of atime occuring during that interval. Yeah, the netapps mess with unix times. Did you notice that mtime and ctime always match? Now that I know you're on a netapp, though, your problems are solved. Snapshot and sync from the snapshot, then

You brought up a very good point which described what rsync can and can not do. Because of the robustness of this application, we are trying to find a way to use rsync and replacing our current primitive system which uses tar and send the data over a small pipe. Since my last posting, I have thought about not using the "--delete"option and instead, gather a list of files to be

- call me ignorant... but I am not above asking. Where do I define $RSYNC_SSH=ssh at? Thanks for the info!! David -----Original Message----- From: rsync-admin@lists.samba.org [mailto:rsync-admin@lists.samba.org]On Behalf Of tim.conway@philips.com Sent: Tuesday, January 15, 2002 7:08 PM To: David L Nickel Cc: rsync@lists.samba.org Subject: Re: SSH Error Ok, you're talking about ssh, and

Approximated petitioner: Perhaps this will help. SunOS 5.7 Last change: 25 Jan 2002 5 User Commands rsync(1) -C, --cvs-exclude auto ignore files in the same way CVS does --existing only update files that already exist --ignore-existing ignore files that already exist

There's nothing in rsync to do that. How about making the files and directories all belong to another user, set the sticky bit and write for your rsync user on the directories, unset write for the files, and rsync that way, then chown afterwards? the updates to existing files will fail, leaving you only with new. Tim Conway tim.conway@philips.com 303.682.4917 Philips Semiconductor -

A: do you have a "hosts allow" or "hosts deny" in rsyncd.conf? B: what version are you using? It seems i've seen messages about rsyncd in some versions refusing to allow unresolvable names in. C: Are you able to access the rsyncd, and just wonder about the log entries, or are you unable to get in? If it's just a log complaint, I wouldn't worry about it. Most

You're set, unless you declined ssh in your cygwin installation (without cygwin, you're not doing rsync from windoze). It's just like unix, in that case. (Bonus clue: Under related commands for ssh, you'll find ssh-keygen). If you don't actually need to secure your content (you're not naked on the internet, for instance), you can just let rsync use plain old rsh

the --pasword-file= option is only for passing a password to a rsync server, as you have set up with the rsync --daemon process. Your rsyncd.conf file is fine, too. The problem is that you aren't calling your rsync daemon from your commandline. You are trying to connect via rsync to host as axlink and start a 'rsync --sender' process, to transfer data within the ssh process.