similar to: Feature Request: break hardlinks before metadata changes

When using --link-dest, this block of code in skip_file causes new copies of files to be created if source and destination file permissions differ, even if -p -o and -g haven't been specified. if (link_dest) { if((st->st_mode & ~_S_IFMT) != (file->mode & ~_S_IFMT)) { return 0; } if (st->st_uid != file->uid || st->st_gid != file->gid) { return 0; } }

Hi -- I was very keen to download rsync and give it a whirl with the new --link-dest feature. However, I was terribly puzzled when I couldn't seem to get it working, even though --compare-dest with the same argument would work. It seemed like new files would be transferred even though files existed in the compare-dest/link-dest location; compare-dest would detect them but link-dest would

Hello, i'm using rsync 2.6.0 for daily-syncing some remote AIX 5.2 machine to a local linux (RH 7.3) with using the --link-dest option for saving space on incremental backups. Even if there are no changes on the AIX machine, all files are newly transferred on every new sync. My test scenario (actisi=remote aix machine, actisa=local linux machine): =====> Initial rsync [mma@actisa

(I'm not sending this to dirvish@pegasus because I think that this message applies more to rsync's --link-dest option than to just dirvish.) I recently noticed a huge spike in dirvish network usage and traced it to files whose permissions had been changed. (with rsync v2.5.6) I understand and agree that a --link-dest copy of a source file cannot be hardlinked to, but couldn't a

Updated to current cvs without the --exclude-from - patch. This patch allows specifying a --link-dest path similar to --compare-dest except that unchanged files are hard-linked to the --link-dest path instead of producing a sparse tree. -- ________________________________________________________________ J.W. Schultz Pegasystems Technologies email address: jw@pegasys.ws Remember

Please CC me directly as i'm not on the list. I have attached a patch against latest CVS (cvs diff -u) that adds the following functionality. I can break it up if you would prefer it in pieces. Comments welcome. o add compare-perms option This creates a new inode for a file even if only the perms have changed. This way if a file outside of destdir is hardlinked to a dentry inside

Hello, I'm trying to do backups with rsync through ssh. This is what I wrote yet: src="/vrmd/webserver/" today=`date +%F` #link_dest="root@vm2:/vrmd/admin/backup/web/2004-09-05" link_dest="../2004-09-05" dest="root@vm2:/vrmd/admin/backup/web/$today" rsync -av -e ssh --delete --link-dest=$link_dest $src $dest in 2004-09-05 (on the dest-server) is the

Hi list, many moons ago I asked about preserving hardlink between identical messages when pigeonhole (for sieve filtering) was used. The reply was that, while hardlink worked well for non-filtered messages, using pigeonhole broke the hardlink (ie: some message-specific data was appended to the actual mail file). Here you can find the original thread:

Il 23-12-2019 12:04 Gionatan Danti ha scritto: > On 19/12/19 11:08, Gionatan Danti wrote: >> Hi list, >> many moons ago I asked about preserving hardlink between identical >> messages when pigeonhole (for sieve filtering) was used. >> >> The reply was that, while hardlink worked well for non-filtered >> messages, using pigeonhole broke the hardlink (ie:

> 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

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

Hi all, I have some questions about hardlinks, alternate storage and compression. I already scanned the list for related information and I have an idea of how things works, but I would like to have a definite answer. System spec: - CentOS 6.6 x64 - dovecot-2.0.9-8.el6_6.4.x86_64 RPM package/version - sdbox mail store 1) About hardlinks: when sending the same message to two different

Hi, I'm having a MAJOR issue with an rsync backup script that is actually OVERWRITING the files that it should be backing up! The thing is, the same script (with different source/destination variables) runs FLAWLESSLY on another file server! Background: 2 OS X client computers running 10.4.11 (1 intel, 1 PPC). both are running rsync v2.6.3. rsync is backing up from one firewire HD(afp

On 14/07/15 08:17, Steffen Kaiser wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Mon, 13 Jul 2015, Gionatan Danti wrote: > >> On the other hand, private (per-user) sieve file works without >> interfering with hardlinks. In a similar manner, disabling sieve also >> permits dovecot to create multiple hardlinks for a single message. >> >>

Hi Javier, thanks for your reply. I already checked SIS and, while interesting, is not what I want, because: 1) it can be difficult to restore a single message/attachment from a backup 2) only the attachments, and not the entire messages, are deduped. Message-based hardlinks really exists for a reason. The good news is that I found _why_ they are not working: it depends from how dovecot and

On 14/07/15 12:26, Steffen Kaiser wrote: > > You asked about "newer dovecot versions", v2.2 does so. > Fair enough :) So, with v2.2+ the hardlink approach is irremediably gone, at least with LMTP (and without relying to SiS)? -- Danti Gionatan Supporto Tecnico Assyoma S.r.l. - www.assyoma.it email: g.danti at assyoma.it - info at assyoma.it GPG public key ID: FF5F32A8

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

Hi folks, I've been googling around for awhile but I can't seem to find an answer to my question. I have a number of filesystems that contain thousands of hard links due to some bad organization of data. Rsync, cpio and various other utilities fail to copy this data because I think there might be some cycles in it. (you know you have troubles if cpio can't copy it!) What I thought

I am using Mike Rubel's snapshot-style rsync to do backups from my web server (Linux) to my desktop (MacOS X). Mostly, this works great, except where case sensitivity (or rather, HFS+'s semi-lack thereof) causes problems. Specifically, it seems impossible to successfully back up my Linux box's /usr/share/terminfo, as it contains directories that differ ONLY in case (e.g.,

Hello guys, sorry for cross-posting, but imho it could be an error in my rsnapshot setup as well as in my rsync setup. If there is a solution on one of these mailing-lists i will post it to the other one as well. ok? here is my question: when running rsnapshot, my exclude filter is being ignored, but i don't see why. grep -v "#" /etc/rsnapshot-debx40.conf | grep . gives