similar to: hardlinking and -R (multiple source directories)

Hi, now it's time to come back to this topic. As supposed, the missing hardlinks where no issue of rsync. I am not sure if pairing aufs (http://aufs.sourceforge.net/) and rsync -RH will catch each and every hardlink compared to a single filesystem, but it seems to work very reliable. I tried mhdfs and aufs. Aufs is faster and very stable (I am on wheezy kernel 3.2). So at last I have my

Hi folks, man page says "By default, rsync will delete any partially transferred file if the transfer is interrupted" I have (reproducible) a partial file left, if I do CTRL-C source-dir: mounted LVM XFS dest-dir: see source-dir Ubuntu 12.04.1 (LTS) kernel 3.2.0-39-generic command: rsync -a

Hi, Version: sync version 3.3.0 protocol version 31 If I do a <rsync -avhHXASDn --del /mnt/ /foo/mnt/> I get: ================= sending incremental file list var/log/journal/ sent 263,31K bytes received 1,14K bytes 528,90K bytes/sec total size is 294,92M speedup is 1.115,21 (DRY RUN) ================= including option <-i>: rsync -avhHXASDin --del /mnt/ /foo/mnt/ I get:

Hi folks, I have a bunch of directories to mirror via rsync. I have lots of hardlinked files spread about these directories. Therfore I use -R (--relative) and -H. so far ok but: I create symlinks to the source-directories via script because src-dirs have changing names (date and time of backup) and I want to have constant directory names on target. How can I achieve that? I thought -k

I have a simple Sieve rule to protect me from accidentally deleting mail: fileinto :copy "backup"; Should I expect this backup to be hardlinked to the ordinary one? Obviously, that would make the backup be almost for free in terms of storage, but currently I do not see any linking. Using Maildir, by the way, and I have not touched the maildir_copy_with_hardlinks setting. TIA,

Have a directory with a bunch rpms in it, mostly x86_64. Have another directory with a bunch, mostly 'noarch'. Some of the noarch files are already in the x86_64 dir and don't want to overwrite them. They are on the same physical disk, so really, just want the new 'noarch' files hardlinked into the destination. sitting in the noarch dir, I tried: rsync -auv

Am 14.11.19 um 15:02 schrieb Paul Slootman via rsync: > On Thu 14 Nov 2019, Pierre Bernhardt via rsync wrote: > So it's looking for b/a as the link-dest directory. > > Use a full pathname for --link-dest to remove all uncertainty. > E.g.: > > rsync -av --link-dest=$(pwd)/a a/ b/ > > In this case, as the destination is also in same current directory, you >

Am 14.11.19 um 10:54 schrieb Paul Slootman via rsync: > You need to specify the source directory as the link-dest directory. Hi, I tried it also because it's an old question which has never worked for me. Instead it creates copies and not hard links: pierre at in94:~/tmp$ ls -li a b a: insgesamt 8 257315 -rw-r--r-- 1 pierre pierre 4 Nov 14 10:53 1 257316 -rw-r--r-- 1 pierre pierre 6 Nov

Hi Justin No i did a test setup after getting to it in real life. In this test setup: - rsync (daemonless) is run - ctrl-c, - results are checked, - dest directory is deleted and so on. in 50 % the file is left over. i can reproduce it on a big fat slow (relative to a small ext4 partition on same lvm) xfs-partition. If i do this on root I even if I manage tp ctrl-c at the right time, I

On 30 Nov 2015, at 10:21, Gionatan Danti <g.danti at assyoma.it> wrote: > > So, let me do a straigth question: is someone using dovecot/LMTP with hardlinking? To me, this seems a _very_ important feature, and I wonder if I am doing something wrong or if the feature (hardlink+sieve) simply does not exists. Hardlink+Sieve has never worked. The fix is a bit complicated. Here's my

> centos 7.x is latest, so if you need help upgrade make a bug report to > centos, not waste your time here since you choiced a precompiled > problem, reporting here 7s helpfull if you use dovecot compiled with > the latest version here, this migth be a unknown bug you then have > found, but not if you use precompiled problems, then report to the > maintainers of such software

Hi all, I have some updates on the hard-link discussion. First, let me explain that I installed a test machine with CentOS 7.1 and dovecot/pigeonhole version 2.2.10-4 and the results where identical on what I had on CentOS 6.7 and dovecot 2.0.9-19 The bottom line is that hardlinking works only when no, or at most only one, RCPT have sieve filtering. For example: - if no RCPT has sieve

Kevin Korb wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > rsync not needed: cp -al dir1 dir2 > Right now, neither is 'cp' (as of V8.21 - V10 inclusive) -- "apparently" (?) in response to this article: http://danwalsh.livejournal.com/64493.html. Right now, 'cp' tries to 'hardlink' to symlinks, which AFAIR has never been an option --

Context ------- I am one of the active developers of the open source application "Back in Time" which uses "rsync" as backend and I want to fix an open issue: "Back in Time"-Bug: https://github.com/bit-team/backintime/issues/994#issuecomment-1724211507 "Back in Time" uses "--link-dest" to reduce traffic and storage by hardlinking

In working on trying to fix the crash issue from my last email I had enabled LMTP delivery to try it out instead of using the LDA. I have discovered that when a single piece of email is to be delivered to multiple users the message is being hard linked instead of copied into each mail box. This is a major problem that makes LMTP unusable in an environment where each mailbox has it's own UID

Hi Timo, glad to know it is in your TODO list ;) Any rough ETA on that? Thanks. On 30/11/2015 14:23, Timo Sirainen wrote: > On 30 Nov 2015, at 10:21, Gionatan Danti <g.danti at assyoma.it> wrote: >> >> So, let me do a straigth question: is someone using dovecot/LMTP with hardlinking? To me, this seems a _very_ important feature, and I wonder if I am doing something wrong or

On 30 Nov 2015, at 17:48, Gionatan Danti <g.danti at assyoma.it> wrote: > > Hi Timo, > glad to know it is in your TODO list ;) It's been for many years. > Any rough ETA on that? Right now it doesn't seem likely to be developed anytime soon. > Thanks. > > On 30/11/2015 14:23, Timo Sirainen wrote: >> On 30 Nov 2015, at 10:21, Gionatan Danti <g.danti

Il 03-01-2020 19:51 @lbutlr ha scritto: > On 03 Jan 2020, at 06:16, Gionatan Danti <g.danti at assyoma.it> wrote: >> What surprises me is that hard-linking identical messages saves so >> much space, yet nobody seems to asking/using such feature. >> So, either a) few cares about saving space or b) few are using the >> pigeonhole plugin. And both a) and b) seems

It appears that xattr changes (that is what the x mens) never made it into the verbose output. I would call that a bug but I would rather it be fixed by making -v include -i. On 6/3/24 05:22, - via rsync wrote: > Hi, > > Version: sync version 3.3.0 protocol version 31 > > If I do a <rsync -avhHXASDn --del /mnt/ /foo/mnt/> > > I get: > ================= >

dear rsyncists, rsync is superb! but did i actually find a bug? i did: $ rsync -vRHSPa rsync://rsync.mirror.ac.uk/updates.redhat.com/7.3/en/os/SRPMS . into an empty local directory the result was 140 bogus hardlinks of the same file: -rw-rw-r-- 140 g g 6147582 2002/12/04 16:55:24 Canna-3.5b2-62.7.3.src.rpm -rw-rw-r-- 140 g g 6147582 2002/12/04 16:55:24