similar to: My email

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.

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

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

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

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 No, even if bandwidth is your concern I would say that --checksum is wrong. Maybe if bandwidth is so scarse that a few KB vs a few MB equates to dollars then sure, use --checksum. Otherwise, letting rsync re-delta-xfer everything is certainly faster and not much more bandwidth intensive than --checksum. Plus that is only if you screwed up and ran

Anyone have any other ideas I could try to debug this issue? :) -- Best regards / Met vriendelijke groet, Aron Rotteveel 2015-03-27 16:02 GMT+01:00 Aron Rotteveel <rotteveel.aron at gmail.com>: > Hi Kevin, > > Just did: same result. > > -- > Best regards / Met vriendelijke groet, > > Aron Rotteveel > > 2015-03-27 14:32 GMT+01:00 Kevin Korb <kmk at

Not to mention the fact that ZFS requires considerable hardware resources (CPU & memory) to perform well. It also requires you to learn a whole new terminology to wrap your head around it. It's certainly not a trivial swap to say the least... Thanks, -Clint On Mon, Apr 6, 2015 at 9:12 AM, Ken Chase <rsync-list-m829 at sizone.org> wrote: > This has been a consideration. But it

I appreciate the parable of helping non-technical users (or, more precisely, users not keen on IT). As I understand, placement of software like Word or Photoshop servers this purpose. But both of them have decent open-source counterparts, and they are better fit for an rsync manual. Or, if from any reason proprietary software is preferred in this context (perhaps because it generates even more

Hi Kevin, Just did: same result. -- Best regards / Met vriendelijke groet, Aron Rotteveel 2015-03-27 14:32 GMT+01:00 Kevin Korb <kmk at sanitarium.net>: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Try it without any --delete options. > > On 03/27/2015 09:31 AM, Aron Rotteveel wrote: > > I am now running with --delete --numeric-ids --relative but the

Sounds to me like maintaining the metadata cache is important - and tuning the filesystem to do so would be more beneficial than caching writes, especially with a backup target where a write already written will likely never be read again (and isnt a big deal if it is since so few files are changed compared to the total # of inodes to scan). Your report of the minutes for the re-sync shows the

Problem was introduced with this commit: commit f3873b3d88b61167b106e7b9227a20147f8f6197 Author: Wayne Davison &lt;wayned at samba.org&gt; Date: Mon Oct 10 11:49:50 2016 -0700 Support --sparse combined with --preallocate or --inplace. The new code tries to punch holes in the destination file using newer Linux fallocate features. It also supports a --whole-file

Ok, thank you for this extra info. I have experienced exactly what you described. The rsync dry run is _still_ running after being started at 1:30am PST :) But it is finding the right files to update. Most of the entries are: >fc........ Which is what I want. So, just because I see: >f at the beginning... That doesn't necessarily mean that the file is going to get updated at the

from MD4 to MD5 (http://rsync.samba.org/ftp/rsync/src/rsync-3.0.0-NEWS). My understanding is that MD5 is a more secure, slower version of MD4 but I am not convinced that the added security of MD5 would alone have merited the change from MD4 (particularly since MD4 is ~30% faster than MD5). I wonder if I am missing other reasons which made the change necessary/desirable? I am looking at ways

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

I am guessing that you would like to use rsync to create a bootable backup. It may also be worth while spending some time looking at CloneZilla or even dd? Dd is a really great tool. You know a copy of the device is bit for bit. You can then use rsync to make incremental copies of these directories which regularly change. In this situation you can restore the machine and then

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. Here's the new repo: https://github.com/WayneD/rsync Feel free to open issues there, but we

Considering you cant INCLUDE a directory that is a symlink... which would be really handy right now for me to resolve a mapping of 103 -> meaningful_name for backups, instead im resorting to temporary bind mounts of 103 onto meaningful_name, and when the bind mount isnt there, the --del is emptying meaningful_name accidentally at times. I think both situations could benefit from a

On Thu, Jun 23, 2016 at 04:09:43PM -0700, Steven Levine wrote: > In <20160623205843.GB6633 at kw.merryville>, on 06/23/16 > at 11:58 PM, Albert Berger <nbdspcl at gmail.com> said: > > Hi, > > >I did some search about this error before asking this question, and in > >other case unsupported ACLs were indeed the cause. But btrfs supports > >ACLs: >