[I'm using the version from the 20051014 nightly snapshot, on Ubuntu Breezy 5.10, which is a Debian-based system, and using an ext3fs filesystem.] It doesn't appear as if rsync correctly hard-links devices together. This came up in the context of dirvish runs which happen to include some filesystem trees of older versions of entire OS disks, so they've got /dev directories in them, etc. dirvish is supposed to crosslink snapshots with each other (courtesy of --link-dest), but it wasn't doing so for these files. And I can't get rsync to do it when I invoke it manually, either---it just always creates the devices anew. I'll either attach (if this bugzilla lets me) or add as a second comment (if it doesn't) a transcript showing this behavior. (There are some pointless switches such as -z in those transcripts because I'm trying to alter the dirvish invocation of rsync as little as possible in testing.) This seems like a bug, since I have no problems manually hardlinking these files together with ln -f, and it's annoying since it clutters up my logs with thousands of spurious transfers (even though dev files are small, they shouldn't be getting redundantly transferred night after night because of this). Thanks!
Created attachment 1518 [details] Transcript of unsuccessful attempts I have other transcripts with me experimenting with all four possibilities of trailing or no trailing slash on the link-dest & source directories, just in case that was confusing things; I couldn't find a combination that worked. (And it can't -all- be pilot error, anyway, since dirvish was having the same problems, and only on the device files.)
Only regular files are currently hard-linked together via --link-dest. I have been hesitant to add to add hard-linking of non-regular files because it will not always be supported and it doesn't save much space, but perhaps it wouldn't be too complex to code this up.
Created attachment 1519 [details] Allow --link-dest to affects symlinks and devices I've worked up a patch for testing that appears to handle things pretty well. It still needs some improvement, though -- i.e. I need to add some code that would discern if a failed hard-link attempt means that a symlink or device cannot be hard-linked, or if just this attempt failed.
Oh! I had no idea --list-dest -wasn't- supposed to work with devices (and symlinks), given that the documentation for the option said nothing about the restriction and given that rsync does handle devices (and symlinks) correctly in other contexts. So I'd say that was a documentation bug... :) In any event, I've applied your patch (thanks! how speedy! :) and rerun my quick test---works fine. (Also passes all the tests in make test, except for two it rightly skipped [chmod-temp-dir and ssh-basic].) I'm now rerunning my full-up dirvish to make sure that works as well; I should know the results in 90 minutes or so (and will comment again if it doesn't work). If you're concerned about this not working in all cases (or on all filesystems---makes it hard to just check at configure time) and maybe tossing spurious errors if it -doesn't- work, I guess there's always the possibility of Yet Another Rsync Option to tell it not to try. I have no particular opinions on that, except that rsync already has a ton of options and adding more just makes that problem worse. I'd certainly say that this should be enabled by default and disabled only when necessary and with some sort of warning or option. (I have no idea if it's safe to hardlink a device if someone -wasn't- expecting it, but it can only happen as root... And if you're running with --link-dest, as root, there's already something fairly unusual going on and I'd argue that it's unlikely to screw a -running- system since you're making a -new- hierarchy that certainly isn't being used as a running system at the time...) Thanks again!
Created attachment 1521 [details] Updated patch There was a bug in the try_link_dest() function when a symlink was being copied with the same name as a non-symlink in the --link-dest dir. This version fixes that.
Created attachment 1522 [details] Corrected update This patch is the right one for the fixed version. Sorry for the confusion.
Thanks! Your first patch worked fine for me in my big dirvish test (because I didn't have any clashing symlinks---at least, on a very casual inspection), but I've downloaded the last patch and reapplied. Still passes make test. (Haven't done any other testing, but this version will be used in the next dirvish run, at least.) And it's certainly eliminated all the log clutter by not retransferring all those devices.
The latest CVS version now has support for hard-linking devices and symlinks via the --link-dest option (and falls back to making duplicates if the OS doesn't allow that).