similar to: rsync file corruption

Hi all, The part about the -S option in the rsync man page says: -S, --sparse Try to handle sparse files efficiently so they take up less space on the destination. Conflicts with --inplace because it's not possible to overwrite data in a sparse fashion. NOTE: Don't use this option when the destination is a

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

Folks, Am 20.06.2016 um 22:01 schrieb Larry Irwin (gmail): > The scripts I use analyze the rsync log after it completes and then sftp's a summary to the root of the just completed rsync. > If no summary is found or the summary is that it failed, the folder rotation for that set is skipped and that folder is re-used on the subsequent rsync. > The key here is that the folder

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

Sent from BlackBerry? on Airtel -----Original Message----- From: rsync-request@lists.samba.org Date: Sun, 28 Oct 2007 12:00:33 To:rsync@lists.samba.org Subject: rsync Digest, Vol 58, Issue 29 Send rsync mailing list submissions to rsync@lists.samba.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.samba.org/mailman/listinfo/rsync or, via email, send a message with

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

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

Hi Rolan, I should have corrected that, my bad! It is an NFS client mounting the NFS server, I.e. nfsClient:/some_dir_mounted_via_nfs Si On 21/07/2015 10:20, "devzero at web.de" <devzero at web.de> wrote: >>Over ssh/nfs >>rsync -nuvaz --delete /source/ root at nfsServer.domain.co.uk: > >i don`t see nfs here, i see rsync syncing a local dir via ssh to a

Steve Sills Platnum Computers, President http://www.platnum.com steve@platnum.com ----- Original Message ----- From: "Steve Sills" <steve@platnum.com> To: "jw schultz" <jw@pegasys.ws> Sent: Thursday, January 22, 2004 1:52 PM Subject: Re: Rsync's Speed > The source server is a Dual 800 Mhz /w a 7200 RPM 40 GB HDD, the dest server > is a P III 450 with a

Subtle bug, simple fix. The problem was introduced by my change that used content hashes to avoid issuing duplicate blobs. The generated .gitignore nodes didn't have a Content-Hash header, which meant all .gitignores were treated as though they had the same *empty* hash. 2.0pre8 is at: http://www.catb.org/esr/nut-conversion/nut-conversion.tar.gz Please check that the .gitignores look OK

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

I have it up and working. for me at least. http://crypotworksapps.blogspot.com/2011/04/windows-and-linux-backups-made-dirt.html On Tue, Apr 19, 2011 at 11:00 AM, <rsync-request at lists.samba.org> wrote: > Send rsync mailing list submissions to > ? ? ? ?rsync at lists.samba.org > > To subscribe or unsubscribe via the World Wide Web, visit > ? ? ?

This sounds like a job for Relax and Recover: http://relax-and-recover.org/ Cal Sawyer | Systems Engineer | BlueBolt On 19/07/15 13:00, rsync-request at lists.samba.org wrote: > Send rsync mailing list submissions to > rsync at lists.samba.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.samba.org/mailman/listinfo/rsync > or, via email, send

I THINK YOUR A VERY SAD BUNCH OF LIFES WAISTERS On Wed, Dec 8, 2010 at 7:00 PM, <rsync-request at lists.samba.org> wrote: > Send rsync mailing list submissions to > ? ? ? ?rsync at lists.samba.org > > To subscribe or unsubscribe via the World Wide Web, visit > ? ? ? ?https://lists.samba.org/mailman/listinfo/rsync > or, via email, send a message with subject or body

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

If your goal is to reduce storage, and scanning inodes doesnt matter, use --link-dest for targets. However, that'll keep a backup for every time that you run it, by link-desting yesterday's copy. Y end up with a backup tree dir per day, with files hardlinked against all other backup dirs. My (and many others) here's solution is to mv $ancientbackup $today; rsync --del

Hi, Which version of Mac OS X are you running? If you are on Mac OS 10.5.x then I can only suggest that you try either formating the drive to HFS + or creating a disk image with an HFS+ file system. If you are running Mac OS 10.4.x then ensure that that ACL support is enabled on the drive. The following URL contains information on how to check and enable ACL support :

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

This is a consolidated reply to your four most recent emails. > I am trying to leverage reposurgeon to automate the process of finding merge > points, and I seem to be spinning my wheels. Can you provide an example of how > you are searching for merges? Not a working one, yet. That code is buggy. It's my next thing to work on. >reposurgeon% merge (apcsmart-dev)