Description of problem: grsync is a front-end to rsync primarily for local backups (such as to an external drive), and seems to work well without the --link-dest={comparison-directory} option. This option can be entered in the extra_options ("Options supplémentaires") section under the "advanced" tab. It is supposed to create hard links to the comparison directory for files in the current backup which are identical, to save disk space. Using rsync directly, as : rsync -aHv --link-dest=/comparison-directory /src-directory/ /dest-directory does correctly create --link-dest hard links. Running grsync, using identical parameters, does not create --link-dest hard links, as though the --link-dest option were not present. So the work-around is to use rsync directly, but grsync does have the advantages of being much easier to use, requiring much less syntax knowledge, and saving backup sessions. Version-Release number of selected component (if applicable): As src rpm. (I used the 64-bit version.) How reproducible: Always Steps to Reproduce: 1. Set up grsync : -- base options tab : * enter source directory with trailing / * enter distination director * check the converse (save?) date + permissions + owner + group boxes (equivalent to -a) * check the information (-v) and progression tabs to see what is happening -- advanced options tab : * check the save-devices, copy-symlinks-as-symlinks, and protect-arguments boxes (all -a), as well as the the hard-links box (-H, which preserves any existing hard links in source) -- other options tab : * check administrator box (unless only backing up personal files). * add the --link-dest=/comparison-directory in the extra options field. Note that it must be on the same filesystem as the destination. 2. Make sure the the destination directory exists, and that that and the source and link-dest directories are correctly specified. (Absolute references are less tricky to specify than relative references with grsync.) The easy way to test is have only a few files, with the comparison-directory a copy of the source. 3. run the configured session by clicking the gear icon at top right 4. use find comparison-directory src-directory -xdev -type f -printf '%i %f -- %h\n' | sort -k 2 > find.tmp and edit find.tmp to see a list of : inodes filename -- path in filename / path order Note that the same filenames do not share the same inodes (i.e. not hard links) 5. create a new destination-directory (dest2) 6. rsync -aHv --link-dest=/comparison-directory /source/ /dest2 (again, trailing / only after source) 7. repeat step 4. Note that there are same filenames with the same inode number, meaning that they are hard linked. Reproducible: Steps to Reproduce:
Shouldn't you use destination folder with find in step 4 instead of source folder when finding the inodes?
CC: (none) => jani.valimaa
You're right, and that is what I did. I should have reread it before submitting. Thanks for noticing it. so step 4 should read 4. use find comparison-directory DESTINATION-directory -xdev -type f -printf '%i %f -- %h\n' | sort -k 2 > find.tmp ...etc BTW, I recently discovered that rsync does these hard links while doing a backup. Then I looked seriously at grsync, which I had installed a while back thinking of testing it. Except for this bug, I really like the way grsync works. By changing just the date in the saved sessions for the destination and comparison folders, it is easy to have a fairly comprehensive set of backups, as well as separating home and other special-purpose partitions from /. Just what I was looking for.
Tested and I can't reproduce your issue. Grsync only passes switches to rsync via GUI so I can't see at this point how it couldn't be working with grsync but working with rsync from cmd. Only way I can partially reproduce this is when I copy files from "source" directory to "compare" directory without preserving the file dates (cp without the -p switch). As creation/modification time differs rsync thinks files aren't unchanged and no hard links are created. Naturally this happens when using both programs, not only with grsync. Dunno if it matters, but I'm using Cauldron with newer grsync.
I (at least almost) always copy things like that with the -a option, which preserves dates, permissions, and owner/group.. And the dates agreed to the second on almost every file I looked at. And the few that didn't I just assumed had been changed. Only 2 things I can think of. Something related is corrupted on my system (not improbable, since gnome3 and/or gtk3 behave quite weirdly at times) ... or maybe the newer grsync in cauldron fixes the bug. I just installed the cauldron version. I'll test it later on. Upstream says the session sets were introduced as experimental in v1.2.1 in mga2. And we have the latest v1.2.3 in cauldron. (Yes, you know since you packaged it :) ) v1.2.3 acquired a very minor display problem. Otherwise it LOOKS the same.
preliminary test using test mode, first on v1.2.3 and reinstalling v1.2.1, both versions pass exactly the same options to rsync. It looks like it was just a glitch on my system. (I've now rebooted twice since my first tests) If it is not a glitch, it could still be an rsync problem. I'll test further this weekend to make sure it's not related to a slight difference in the options used by grsync. There was an extra option not documented in the translated man page, plus the order was quite different. Also the -a option is split by grsync into all its' components. If splitting causes a problem for rsync, adding an explicit -a option to grsync would work around it, as well as simplifying grsync for users.
ok, thoroughly retested -- works perfectly now, so must have been a glitch in my system.
Status: NEW => RESOLVEDResolution: (none) => INVALID