Re: Serious issue: rsync and hardlinks are dangerous...

> Also, this is already reported, but a bit "forgotten" (last comment > was three years ago): I think if search the zilla, you find quite some open ticket on hardlink issues still? :( As in some of those tickets, provide your replicate command sequ

Re: [Bug 8856] New: --hard-links does not handle hard-linked symlinks correctly on FreeBSD

What are the FreeBSD and Linux 'a' filesystem types? Please post the list of commands used to recreate the FreeBSD directory 'a', starting from rm -rf ./a. -- Please use reply-all for most replies to avoid omitting the mailing list. To unsubscribe or change options: https://lists.samba.org/mailman

Re: Re: cwRsync got killed...

> Side question: Does anyone know the probability of generating a file with > the same md5 and sha256 which is still looks valid with the expected content Uhh, zero. Problem is, the author never bothered with or knew about PKI signatures. So the hashes on the web could be wrong. Note also that th

Re: "non-efficient" sparse file copying with rsync

> The question is whether it is possible to copy sparse files as sparse, but > to preserve the original file size? By file size I mean the size, that a > file actually occupies on file system as reported by "du --block-size=1 > FILE". The apparent size is always the same. If supported by your plat

Re: Regression: sockets for 3.0.9pre1 ?

> If you want to help solve this Yes :) The system now also passes memtest86. > do some experiments with a single socket or special file I've not found a broken example of that yet. To date it has required at least a smallish tree, with some hardlinks in it. > find the shortest path length at

Re: Regression: sockets for 3.0.9pre1 ?

Here are two verbose outputs. One comparing a dir, the other a problem file in that dir. The long path component has been shortened to '/.../'. The files in question are: # src, aka: NULL 3022430 0 crw-r- 2 0 0 - 9, 67 Oct 11 00:23:14 2007 fd1.1440 3022430 0 crw-r- 2 0 0 - 9, 67 Oct 11

Re: Regression: sockets for 3.0.9pre1 ?

> There's no reason rsync would be doing anything differently from prior > versions, so check what's wrong with your system. Hmm, I have syslog *.* going to disk, no kernel or other issues reported. 3.0.8 was compiled on this system. fsck -fy reports the source and dest are clean. I do know that

Re: Regression: sockets for 3.0.9pre1 ?

I should also note that it does not revert them back once you do happen to get a good sync... rsync /shortpath1/ /shortpath2/bad initially rsync /longpath1/ /longpath2/fixes things rsync /shortpath1/ /shortpath2/no change But that even remounting the filesystems directly on the root (

Re: Regression: sockets for 3.0.9pre1 ?

Ok, largely in pseudocode After verifying the mountpoint directory list counts were the same... find -sx /.../each_mountpoint -ls | wc -l [good] I looked closer at the pathnames in the dirs that had the sockname in question... find -sx /.../mountpoints/... | diff [bad] So now to look a

Regression: sockets for 3.0.9pre1 ?

Hi. rsync 3.0.8 FreeBSD RELENG_4 i386. rsync -Haxi --delete /.../ /.../ The first pathspec above (residing on zz, a full filesystem) is: ////zz/ The second pathspec above (residing on yyy, an empty filesystem) is: ////yyy/zz/ It's obviously a 'copy everything over' opera

Re: ZFS NFSv4 ACLs Support

> I've noticed that rsync does not currently support ZFS NFSv4 ACLs. If I were > to create a patch to enable support, would rsync accept it or should I > submit the patch to IllumOS? Either way, I'll be creating a patch. I just > want to know if upstream would like the patch. Surely many ZFS users

Re: recent discussion regarding 'checksums'

> Also as I think Wayne pointed out, using "-c" isn't very common in the first > place. > transfer. The delay due to I/O wait is going to be orders of magnitude higher > than any reasonable hash computation. In a parallel life, I also mirrored some websites generated from database backends. Fo

Re: recent discussion regarding 'checksums'

> If Ad nauseum... to each shall entertain their own use case scenarios. The overall point is that MD5 is not suitable for data integrity beyond it's known [and unknown] weaknesses. I've no faith in an algorithm with such freely generatable collisions to not have other collisions/rot with any of t

Re: recent discussion regarding 'checksums'

> Yes, right now "rsync -c" is not good if an attacker has had the > opportunity to plant files on the destination and you want to make sure > the files get updated properly, but that's an uncommon use case Or whitehat people backing up cracked boxes. Or anyhat people backing up data generated

recent discussion regarding 'checksums'

Hi. Wanted to add something. There was recent talk about the use of 'checksums' by rsync to determine how or what parts of a file to copy. Something like that. Anyways, it just so happens that I have a number of files here that rsync completely fails to update... l -isT */* ; md5 -r */* ; sha1 -r

Re: Abysmal sparse file performance!

> "stand-alone" mode to copy from and to the same computer. Yes, however that is a valid and common use case, and one in which rsync needs to compete. > it will use the delta algorithm to do not transfer all the files Though unrelated to the above, that's a fine summary of another one of rsync's

Abysmal sparse file performance!

I have a 5.5GB file, mostly sparse. Tar performs far[!] better than rsync. I have no ideas yet, so just an FYI as to current state. FreeBSD 8.1 i386 zfs Yes, I know the blocks used differs but don't know why yet, could be just how zfs does things or related to the large amount of sparseness. There

Re: rsync --link-dest, --delete and hard-link count

>>> cp -al, rsync >> Various source changes would likely change some metadata in the old >> sets. > Yep. See my request for a --no-tweak-hlinked option to avoid such > https://bugzilla.samba.org/show_bug.cgi?id=4561 This is interesting. Though it would have more uses than being just another bolt

Re: rsync --link-dest, --delete and hard-link count

> cp -al, rsync Various source changes would likely change some metadata in the old sets. And it doesn't handle those pesky multiple link-dests. > overhead ... dirvish ... find ... etc In C, in rsync, would be a more efficient general solution than any particular bolt on equivalent. > option O

rsync --link-dest, --delete and hard-link count

I goofed up one part of this: Since things are stored in hierarchy, not flat... it's not the sum of all the full pathnames. But the sum of the names in each directory and the sum of all those sums. Adjust theory minimums accordingly. Still can use great gobs of space though, easily overlooked. A

Re: rsync --link-dest, --delete and hard-link count

>> Huh? See now? :-) > That seemed excessive to me, too. In a short test it seems accurate. Yep, it is. > And, it's a slow process on my machine Ramdisk is good for such empty file tests. And you can blow it away in a second by simply nuking the core. Instead of waiting for rm to grind the r

Re: rsync --link-dest, --delete and hard-link count

>> Files that are present in the previous datedir/hier/run but will >> not be present in the currently to be made datedir/hier/run, >> [because they are no longer present in the source hier], >> DO NOT show up in the output of rsync -i as deletions. > > As they shouldn't, as they're not deleted. >

Re: rsync --link-dest, --delete and hard-link count

Beware when using rsync --link-dest, --delete -Haxi !!! Files that are present in the previous datedir/hier/run but will not be present in the currently to be made datedir/hier/run, [because they are no longer present in the source hier], DO NOT show up in the output of rsync -i as deletions. Sur

Ignoring parts of stat(2)

> That option can be easily missed it's: --size-only That seems like at least part of what would be useful :) Certainly it covers the most common case of modtimes. However, it doesn't seem to work :( cp -p /etc/passwd a cp -p /etc/passwd b ls -liT a b 5 -rw-r--r-- 1 user wheel 1706 Dec 25 03

Ignoring parts of stat(2)

How do I make rsync ignore and not report or update certain parts of the [l]stat(2) struct or checksum when selecting which items to report or update in a hierarchy? For example, I want to run: rsync -Haxi --delete /hier1/ /hier2/ and have it NOT do anything if say ONLY the modtime differs. Leavi