similar to: Seemingly impossible bug: -v not always listing every copied file

Thanks. I'll try that. But I agree that it'll be something else. It's unlikely that whole trace files are being overwritten, because there's locking in place to prevent that sort of thing, but it's more likely than anything else. I'll check that the locking is working properly. Although, when I last investigated it, it really did look as though, in a single run of this

Hi raf, Curious issue you have. A few things: What distro(s) are you using? Same rsync version on both ends? Hash of files look correct before and after the rsync? Have you tried using inotify to monitor for changes at the fs level? You should see a "read" on the sender and a "read" + "write" on the receiver. On Tue, Oct 29, 2019, 11:25 PM raf via rsync

If you are doing a small test run that duplicates the problem, you could use inotifywait or tail -f to watch the log in real time on another terminal. Maybe you'd see something like a line being overwritten, etc. I don't know what rsync would do with a file name that ends in a carriage return (not a newline). It's probably smart enough to handle it, but if it isn't, the current

It does seem impossible. I would suggest adding --itemize-changes (-v isn't really all that useful without it anyway). If entries are still missing then I would suspect that either log files are missing (maybe duplicate file names replacing the occasional log file?) or something other than rsync is doing things in the same dir. On 10/29/19 9:00 PM, raf via rsync wrote: > Hi, > >

Rsync is a remarkably handy tool that I use virtually every day. But there is one thing about rsync that drives me totally crazy. Under the -n (dry run) flag, rsync seems to produce exactly the same output as without that flag. I cannot tell you how many times I sit and scratch my head long and hard,after I discover that my intended rsync operations did not actually happen. Until I finally

On Wed, Sep 30, 2020 at 03:35:43PM +1000, Damien Miller <djm at mindrot.org> wrote: > On Wed, 30 Sep 2020, raf wrote: > > > Hi, > > > > I have a VM with a git repository whose origin is on > > github. I have several keys known to github, so I needed > > to set git's core.sshcommand config parameter in the > > repository to something like this:

Hi, I have a VM with a git repository whose origin is on github. I have several keys known to github, so I needed to set git's core.sshcommand config parameter in the repository to something like this: ssh -i ~/.ssh/id_ed25519_github2 But it meant that I needed to copy that key to the VM. The same key is available via my forwarded ssh-agent connection. Is it possible to tell ssh to use

On Tue, 4 Aug 2020, raf wrote: > In such cases, this vulnerability can be mitigated by > the use of an ssh-specific command whitelisting control > such as: Probably just as easy: give the user a restricted shell (/bin/rmksh) as shell and set their PATH etc. suitably, to not include any other commands. bye, //mirabilos PS: Full disclosure: I?m the mksh developer -- ?MyISAM tables

Hi All I have setup a new dev system running LinuxMint 9 (Ubuntu 10.4). Running ruby 1.9.2, rails 3.0, RVM etc. One issue I have run into is that I can''t stop webrick with ctrl+c or ctrl+d and killing the terminal always leaves a stranded ruby process. Has anybody else run into this? Btw, webrick gets started by running "rails s" in. Also, ctrl+c works fine to stop a

Feature request: allow --link-dest dir to be linked to even if file exists in target. This statement from the man page is adhered to too strongly IMHO: "This option works best when copying into an empty destination hierarchy, as rsync treats existing files as definitive (so it never looks in the link-dest dirs when a destination file already exists)". I was suprised by this behaviour

It seems that there are a few camps here: * The scp power users - this camp believes that scp supporting backtick notation is fine and that running arbitrary commands is a perfectly fine thing to do. * The restricted shell users - this camp believes that scp supporting backtick may not be the best, and there are various restricted shells which can prevent this. Power users may belong to this

This has been a consideration. But it pains me that a tiny change/addition to the rsync option set would save much time and space for other legit use cases. We know rsync very well, we dont know ZFS very well (licensing kept the tech out of our linux-centric operations). We've been using it but we're not experts yet. Thanks for the suggestion. /kc On Mon, Apr 06, 2015 at 12:07:05PM

Hello, rsync list folks, Recently, rsyncs abort during busier times of the day, although they run error-free during non-busy hours. Problem 1 - Many rsyncs abort these errors: Read from remote host www.xxx.yyy.zzz: Connection reset by peer rsync: writefd_unbuffered failed to write 4 bytes [sender]: Broken pipe (32) rsync: connection unexpectedly closed (3929920 bytes received so far)

raf via rsync wrote: > Georg Limbach via rsync wrote: > > > Hello, > > > > I have a problem while rsyncing a directory with perhaps 1.000.000 > > files. Before this I generate some files locally and add them to temp > > files. So this files should be excluded from syncing. > > > > My rsync call looks like this: > > > > rsync

For backuping system folders on ArchLinux I use the following command per folder: rsync --update -DHAErlptgo --relative --delete-during $dir $backupdir The problem is that every file in /root folder and its subfolders is copied each time when this command is run. In all other folders only new or modified files are copied. The files and the folder itself have the following attributes: [root at

Hi raf, I was not aware the network maps were "user experience". Thanks for your tips. I have tried everything I can come up with, but cannot get it to work. I figured out another solution, but thank you very much for your help. Best, Leon On Sun, Mar 29, 2020 at 9:23 PM raf via rsync <rsync at lists.samba.org> wrote: > Leon Vanderploeg via rsync wrote: > > >

Hello all, This is my first post to this mailing list. I have been using rsync for a bit and have it mostly working the way I want. I have a backup server that I run all scripts from. It rsyncs data from four different Linux servers via cron. A sample of a script is here: rsync -avz --log-format="%t %b %f %l %M" --delete --stats -e "ssh -i /root/rsync/authors-rsync-key"

I hear you - but it seems that the choice is between (a) limiting "scp" functionality to address the security vulnerability, and (b) killing "scp" altogether. I'd much prefer (a), even if it means I lose "scp remotehost:foo\* .". Especially, since (almost always) I have equal privileges on both local and remote hosts, so in that case I just originate that

On 12/03/2014 01:37:58 PM, Kevin Korb wrote: > As far as a backup provider goes I wouldn't expect them to use rsync > over SSL unless that were built into rsync in the future (and has > been > around long enough that most users would have it). > > I would expect them to either use rsync over ssh secured by rrsync or > rsyncd over ssh with them managing the rsyncd.conf

hi, i've just set up two new computers each with a Powerware 3105 ups. they have identical nut configurations and identical upss which are both plugged in via usb but only one is being detected by nut. the other keeps saying: Broadcast Message from nut at server-1 (somewhere) at 14:52 ... UPS ups at localhost is unavailable i tried plugging the ups into several different usb