advertisement

Article:
  Automated Backups on Tiger Using rsync
Subject:   Beware rsync's huge bug...
Date:   2005-07-22 16:18:17
From:   mechanist
Rsync is fantastic for backups... except if you use the version included with Tiger, as described in this article, you'll likely encounter a big honking bug.


Beginning with Tiger there's the "-E" option that specifies "extended" attributes such as resource forks should be copied. Great, right? But if you use "-E" and "-a" (archive) together, as you would for a backup, the modification dates of the copied files will be incorrect.


With "-a" the modification date of the copied file should be the same as that of the original. But with "-a" and "-E", and when the file has a resource fork, the modification date of the copied file will match the date OF THE COPY, not of the original file.


I reported this to Apple for 10.4; they marked it as a duplicate. The bug is still present in 10.4.2.


For now you're better off using the version of rsync included with RsyncX.
Full Threads Oldest First

Showing messages 1 through 8 of 8.

  • Beware rsync's huge bug...
    2005-09-28 02:02:32  maceis [Reply | View]

    This is true, but only files which have a ressource fork are affected.
  • Beware rsync's huge bug...
    2005-07-23 23:35:44  KonradHosemann [Reply | View]

    The rsync od RsyncX has the same problem, as well as hfsrsync from darwinports, which is the same as the RsyncX rsync, I guess.

    Do you know an rync which definetly doesn't have this bug?
    • Beware rsync's huge bug...
      2005-07-26 15:00:58  mechanist [Reply | View]

      In my experience, the version of rsync included with RsyncX definitely does not have this bug. I use it all the time and have observed no problems like the one I described.

      With the RsyncX version the command you'd use is:

      rsync -a --eahfs SOURCE DEST

      This should be equivalent to "rsync -aE" with Tiger's stock rsync.

      In my usage the modification dates are correct, both for copying to a different drive on the same system and for copying to a remote system over ssh.
  • Beware rsync's huge bug...
    2005-07-22 16:31:15  Corvus [Reply | View]

    Thanks Mechanist; I've been using rsync for months and never noticed that. rsync compares file data, it doesn't use the modificatin date, but still...

    I'll try it with RsyncX.
    • Beware rsync's huge bug...
      2005-07-23 15:10:41  joseph p.muscara [Reply | View]

      I've been using RsyncX for ages, but the problem I've had lately is that I can't get it to run properly as a cron job. It consistently causes a kernel panic on my 10.4.2 Server. I was hoping that switching to rsync would solve my problems.

      If anyone has any suggestions about using RsyncX as a cron job, I'd appreciate it; I did use the fix for the bug in the script generator to make sure the cron job was using /usr/local/bin/rsync.
      • Beware rsync's huge bug...
        2005-07-24 05:06:54  Corvus [Reply | View]

        Hi Joseph. Is your problem with rsync or cron? If it's the latter, my suggestion is to use iCal events as shown in the article, not cron.

        I know Linux users will be aghast, but I have found iCal events much easier to create, manage, control, and understand than cron. And there is negligible difference in performance if you're just running the command once a day or so.
      • Beware rsync's huge bug... (and more)
        2005-07-24 02:49:48  Alexander_Lamb [Reply | View]

        Several remarks here:

        1)
        I use file vault. To avoid backuping the sparseimage in addition to the decrypted data, I use this:

        sudo rsync -Eavb --delete --backup-dir="/Volumes/alamb_bck/rsync_bck" --exclude="alamb.sparseimage" /Volumes/DATA/Users/alamb "/Volumes/alamb_bck"

        However, since I don't want to leave an unencrypted backup on a machine somewhere on the network on on my portable drive, I create an encrypted sparse image that I mount for the destination.

        2)
        I managed this mounting from a Windows SMB volume. Doing this you avoid the ressource forks issues. (since you are backuping to hfs+ and not ntfs).

        3)
        There is a bug (Apple calls it a feature) which makes rsync recopy systematically ALL the resource forks of the files.

        4)
        I consistently had "broken pipe" errors when I had my source volume (where my home is) as hfs+ journaled WITH case sensitivity.

        5)
        Some files (other than resource forks) get systematically backed up (iPhoto photos for example). No way to tell why. Obviously it takes ages.

        6)
        I never managed to have rsync run consitently with crashing on broken pipes or other issues. For me, it is not ready to prime time on MacOSX (RsyncX had the same problem).

        7)
        It looks like there are fewer problems when backuping through rsh with ssh.

        8)
        There must be a squeduling issue with rsync. I have a power book with 1 gig ram but when I am runing rsync I hardly can move the mouse or type a text in text edit!!

        9)
        Someone on a forum suggested it was the --delete creating problems. But how should I backup correctly without --delete and without at least archiving what is deleted??

        Well, I am at the point where the time I wasted trying to make all this work cost me more than a 50$ sync program such as ChronoSync, SynchronizeProX, TriBackup or YouSynchronize.

        Any hint as to where I should go to now??

        Alex
        • Beware rsync's huge bug... (and more)
          2007-08-30 04:20:30  Blue80 [Reply | View]

          After many hours and much fiddling trying to get backup happening. Rsync Lart 2.6.6 Darwinports version finally works for me on Tiger

          http://rsync-lart.darwinports.com/

          The broken pipe errors are finally gone.

          Well as good as it can....see Backup Bouncer for independent testing of capability:
          http://www.n8gray.org/blog/2007/04/27/introducing-backup-bouncer/