similar to: (no subject)

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,

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

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

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 -

Ah... there's your answer. ssh is working fine, as you say, but you're invoking rsync without telling it to user ssh, so it's using rsh. If you've got this, you don't need rsyncd.conf. The syntax you're using tells rsync to use an external transport. rsync -e ssh file rmt_host:/tmp Tim Conway tim.conway@philips.com 303.682.4917 Philips Semiconductor - Longmont TC 1880

I have a similar problem with rsync, though it's not consistent. sometimes, things just don't come over, and sometimes, things just don't get deleted. Repeated runs usually correct it. If it's the case of a directory being replaced with a non-directory, you'll have to add "--force" to get it to happen. Hope it helps. Tim Conway tim.conway@philips.com

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.

If you're planning to rsync it over, tar it up, and delete the directory tree, you should just tar|gzip it on the work system and catch that in a file on the other end. 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

This is where it sets a sort of 60 second timeout if you don't set a timeout at all. As far as what it affects, I'm not that good with the code. I just know that my big syncs would die in almost exactly 1 minute unless I specified a timeout, and then would die at that timeout until i got it very large. +++++++++++++++++++++++++++++++++++++++++++++++++++++ Tools@willy

I see very odd results from rsync 2.4.7pre1, the latest cvs version (sept 12, i think was the last modified file). We have a number of network-attached storage devices. 10/100 ethernet, nfs2 mounted (under nfs3, they buffer deletes, and recursive deletions fail). Usually, these are kept syncronized across a wan by a nightly cronjob, We have a few we keep in reserve, which we syncronize

I'm not sure what the problem is. Here's a snip of my log (very similar setup, but from server to remotes): 2001/05/17 14:26:59 [29226] rsync on ToolSyncModules/ToolSyncModuleList from irvnetsvr (134.27.9.31) 2001/05/17 14:27:00 [29226] wrote 23292 bytes read 128 bytes total size 23179 2001/05/17 14:27:01 [29227] rsync on ToolSyncModules/ToolSyncMastersList from irvnetsvr

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....

I just did a win2k install, and as I thought i'd remembered, it asked whether the hardware clock was UTC or localtime (and recommends localtime). Of course, I chose UTC, but most would probably follow MegaSloth's recommendation. I don't know how to change it on an already-installed system, though. Does anyone else? Tim Conway tim.conway@philips.com 303.682.4917 Philips

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

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

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 vote for the consistent, complete log format as a solution to this sort of thing, and those who need to take non-rsync related actions based on what rsync did can write their own applications to do so. People keep coming up with some particular thing they need done for their own application, and want rsync to do that too. rsync is a tool to make one thing exactly like another. It is not

That's the way it is. If it's really a one-off change, a huge change in your structure, telnet ssh, rsh, and so forth, work really well for dropping in and deleting stuff (unless you're supplying the master, and other systems out of your control copy from you). Rsync is optimized for taking a filesystem in an unknown state, and making it identical to another filesystem in an unknown