similar to: "No such file or directory" error!

https://bugzilla.samba.org/show_bug.cgi?id=8060 Summary: "hosts allow" in rsyncd.conf doesn't handle IPv6 subnets smaller than /64. Product: rsync Version: 3.0.8 Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: P5 Component: core AssignedTo:

Hi, In 3.0.4, encountered a problem with dot-dir path (e.g. , foo/./bar) inside a -files-from file when the root of the transfer isn't in the current directory. This was fixed in 3.05 (well, partially). 3.0.5 bug fixes release info: - Fixed the use of a dot-dir path (e.g. foo/./bar) inside a --files-from file when the root of the transfer isn't the current directory.

hello, I'm running an Gentoo distribution on my computer, lately I've started to get error messages that are rsync related. here is a log of the output: Fetching most recent snapshot Attempting to fetch file dated: 20080219 portage-20080219.tar.bz2: OK Syncing local tree... building file list ... rsync: link_stat "/var/tmp/emerge-webrsync/portage/180" failed: No such file or

https://bugzilla.samba.org/show_bug.cgi?id=6116 Summary: Cannot access files in exposed shadow drive in version 3.0.5 Product: rsync Version: 3.0.5 Platform: x86 OS/Version: Windows NT Status: NEW Severity: normal Priority: P3 Component: core AssignedTo: wayned@samba.org

Greetings, I am using cygwin/rsync to backup windows data to a linux server. I recently upgraded an implementation of rsync from 2.6.8 to 3.0.4 and have encountered a problem. In the previous version of rsync a /./ in the from file would cause the previous path information to be dropped for the destination directory. In 3.0.4, it appears the . is being translated into the current (working)

Any ideas anyone? I still need at least a weekly backup of all data. The current workaround is just for the most active directories. Are there any diagnostics I can do which might shed some light on this? Thanks JohnOn 4 Jan 2019 09:53, John Simpson via rsync <rsync at lists.samba.org> wrote: > > Kevin > > The link-dest parameter is a single directory (the previous day's

On Wed, Apr 22, 2015 at 9:15 AM, Kevin Korb <kmk at sanitarium.net> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Normally, I would say that --checksum is actually slower than just > letting rsync re-copy everything Depends on the network capacity and costs associated with that bandwidth :( >and therefore is almost always the > wrong thing to do. Nope,

> On 25 May 2020, at 23:55, Wayne Davison via rsync <rsync at lists.samba.org> wrote: > > I've decided to give hosting it on github a try, especially since there's been a lot of nice contributions lately. Hopefully this will make it easier for both the people sending patches as well as for me to snag the changes. I'll continue to push changes to the samba git as well.

Peter, I was about to post the below to the rsync mailing list, but wondered whether your code which captures rsync output may have allowed rsync to continue past what I think would normally be a fatal error? Thanks Rob. P.S. Should I put the final backups of the old pearcey /home back into their correct slots - 5 backups were recycled, but nothing was added to them? The .Snapshots area is

Exit code 2 is "Protocol incompatibility". Also, sounds like what you really want is --files-from On 04/07/2017 10:01 AM, Axel Kittenberger via rsync wrote: > With this two options on a very live system you may need to take into > account this bug as well I reported a while ago: > > https://bugzilla.samba.org/show_bug.cgi?id=12569 > > Due to this I'm currently

https://bugzilla.samba.org/show_bug.cgi?id=12527 Bug ID: 12527 Summary: Sender waits for timeout when fuzzy basis file found Product: rsync Version: 3.1.2 Hardware: All OS: All Status: NEW Severity: critical Priority: P5 Component: core Assignee: wayned at samba.org

I think --partial might be a red herring here. It only applies to what happens when rsync is aborted in the middle of a file. What happens without -P? Also, it is worth trying with --inplace. On 12/30/18 5:32 PM, Heiko Schlittermann via rsync wrote: > Hi, > > I used --partial to transfer files from my local computer (rsync 3.1.2, > Debian) to a remote computer (rsync 3.1.1 WD

problem is he's trying to rsync into the target dir and have the side effect of delete. so an empty dir would necessarily need to be in the target of course and thus created there, triggering the quota block. he tried to avoid this by using device files then 'blocking all device files' but i think rsync figures out first there's nothing to do, so it just stops and doesnt do the

Hi Ram, In OS X, some font types (not all) put the font payload in the resource fork. Netatalk provides AFP filesharing, imitating the resource forks by creating secondary files in ?.Appledouble? folders within each folder. Netatalk tracks the resource forks, and other metadata, by keeping a ?Desktop database? at the root of the shared volume ? look for .AppleDesktop, and .AppleDB. You can

The errors column is 0. The drop column is 18. The second bit number is the number of packets which should grow. At least that is how I read it. Column makes it more readable in a terminal but not so much in an email. On 12/21/23 14:18, Alex wrote: > Can someone help me determine if these errors are normal or if this > could somehow be the cause? I've removed the last three

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

Kevin The link-dest parameter is a single directory (the previous day's directory), the destination is today's directory. I haven't tried deleting a backup, there's no particular need in space terms, at the current rate there's enough space for several years of daily backups. I've reverted to daily backups on a small subset of the total; the full backup now takes

There are times when a large file is copied up to 99% and then deleted after having received the error. Other times when the error occurs earlier and only a part of it is copied. Does it make sense to calculate the checksum if in both cases in output I don't have the same information that there is in input ? Because in the first case it is totally deleted and in the second case I have only a

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 if you see >f it is doing something to the file. At least a delta-xfer. If it was just a metadata change it would show cf. If you see an >fc without a t then that is an example where rsync found a file that didn't match even though the timestamps did. That isn't supposed to happen very often. On 10/28/2015 01:19 PM, Clint Olsen

On 8/05/2017 9:13 PM, Aki Tuomi wrote: > > > On 2017-05-08 13:52, Reuben Farrelly wrote: >> Hi, >> >> Following up on this as there has been no response and the problem is >> still present. As this is the master-2.2 branch I would have thought >> it would compile most of the time... >> >> Thanks >> >> >> On 28/04/2017 7:27