Description of problem: I was running my daily backup for the first time on a new F11 system. After the script finished looping over all of the paths the log showed the following Python error: Exception 'RORPath instance has no attribute 'path'' raised of class '<type 'exceptions.AttributeError'>': File "/usr/lib64/python2.6/site-packages/rdiff_backup/Main.py", line 304, in error_check_Main try: Main(arglist) File "/usr/lib64/python2.6/site-packages/rdiff_backup/Main.py", line 324, in Main take_action(rps) File "/usr/lib64/python2.6/site-packages/rdiff_backup/Main.py", line 280, in take_action elif action == "backup": Backup(rps[0], rps[1]) File "/usr/lib64/python2.6/site-packages/rdiff_backup/Main.py", line 343, in Backup backup.Mirror_and_increment(rpin, rpout, incdir) File "/usr/lib64/python2.6/site-packages/rdiff_backup/backup.py", line 51, in Mirror_and_increment DestS.patch_and_increment(dest_rpath, source_diffiter, inc_rpath) File "/usr/lib64/python2.6/site-packages/rdiff_backup/backup.py", line 243, in patch_and_increment ITR(diff.index, diff) File "/usr/lib64/python2.6/site-packages/rdiff_backup/rorpiter.py", line 284, in __call__ branch.start_process(*args) File "/usr/lib64/python2.6/site-packages/rdiff_backup/backup.py", line 718, in start_process ("Either %s or %s must be a directory" % (repr(diff_rorp.path), Traceback (most recent call last): File "/usr/bin/rdiff-backup", line 30, in <module> rdiff_backup.Main.error_check_Main(sys.argv[1:]) File "/usr/lib64/python2.6/site-packages/rdiff_backup/Main.py", line 304, in error_check_Main try: Main(arglist) File "/usr/lib64/python2.6/site-packages/rdiff_backup/Main.py", line 324, in Main take_action(rps) File "/usr/lib64/python2.6/site-packages/rdiff_backup/Main.py", line 280, in take_action elif action == "backup": Backup(rps[0], rps[1]) File "/usr/lib64/python2.6/site-packages/rdiff_backup/Main.py", line 343, in Backup backup.Mirror_and_increment(rpin, rpout, incdir) File "/usr/lib64/python2.6/site-packages/rdiff_backup/backup.py", line 51, in Mirror_and_increment DestS.patch_and_increment(dest_rpath, source_diffiter, inc_rpath) File "/usr/lib64/python2.6/site-packages/rdiff_backup/backup.py", line 243, in patch_and_increment ITR(diff.index, diff) File "/usr/lib64/python2.6/site-packages/rdiff_backup/rorpiter.py", line 284, in __call__ branch.start_process(*args) File "/usr/lib64/python2.6/site-packages/rdiff_backup/backup.py", line 718, in start_process ("Either %s or %s must be a directory" % (repr(diff_rorp.path), AttributeError: RORPath instance has no attribute 'path' failed to backup '/root' to '/mnt/backup//root' Version-Release number of selected component (if applicable): rdiff-backup-1.2.8-1.fc11.x86_64 python-2.6-9.fc11.x86_64 pylibacl-0.2.2-6.fc11.x86_64 pyxattr-0.4.0-3.fc11.x86_64 How reproducible: Only happened once so far. Steps to Reproduce: 1. run rdiff-backup --exclude-special-files --exclude-globbing-filelist /etc/cron.daily/rdiff-backup.excludes "$backup_source" "/mnt/backup/$backup_source" || abort "failed to backup '$backup_source' to '/mnt/backup/$backup_source'" where backup_source=/root 2. 3. Actual results: The error above message above. Expected results: rdiff-backup process should return a non-error code Additional info: I don't have many files in /root right now: # tree -a /root/ /root/ |-- .bash_history |-- .bash_logout |-- .bash_profile |-- .bashrc |-- .cshrc |-- .gconf |-- .gconfd | `-- saved_state |-- .htoprc |-- .lesshst |-- .recently-used.xbel |-- .tcshrc |-- .viminfo `-- anaconda-ks.cfg 2 directories, 12 files
Looks like a second backup just finished running and although it finished successfully rdiff-backup printed this when running the same command on /root: Previous backup seems to have failed, regressing destination now. Warning: Could not restore file manual-backup.log! A regular file was indicated by the metadata, but could not be constructed from existing increments because last increment had type None. Instead of the actual file's data, an empty length file will be created. This error is probably caused by data loss in the rdiff-backup destination directory, or a bug in rdiff-backup
I forgot to mention the contents of /etc/cron.daily/rdiff-backup.excludes: **core.* **/plouj/games **/plouj/Download **/plouj/Videos
Odd. What filesystem type/device is /mnt/backup? ie, can you add output of 'cat /proc/mounts' here?
# cat /proc/mounts rootfs / rootfs rw 0 0 /dev/root / ext4 rw,seclabel,relatime,barrier=1,data=ordered 0 0 /dev /dev tmpfs rw,seclabel,relatime,mode=755 0 0 /proc /proc proc rw,relatime 0 0 /sys /sys sysfs rw,relatime 0 0 none /selinux selinuxfs rw,relatime 0 0 /proc/bus/usb /proc/bus/usb usbfs rw,relatime 0 0 devpts /dev/pts devpts rw,seclabel,relatime,gid=5,mode=620,ptmxmode=000 0 0 /dev/sdb1 /boot ext3 rw,seclabel,relatime,errors=continue,data=ordered 0 0 /dev/mapper/backup--disk-main--backup--volume /mnt/backup ext3 rw,seclabel,relatime,errors=continue,data=ordered 0 0 tmpfs /dev/shm tmpfs rw,rootcontext=system_u:object_r:tmpfs_t:s0,seclabel,relatime 0 0 none /proc/sys/fs/binfmt_misc binfmt_misc rw,relatime 0 0 sunrpc /var/lib/nfs/rpc_pipefs rpc_pipefs rw,relatime 0 0 (I haven't had time to upgrade it to ext4 yet)
That should be fine. I see some other reports around that it might be related to the '--exclude-special-files' option. Have you seen it again since that first time? Was that an inital backup?
I have only seen it once - the first time I backed up this install of F11. However, the target backup directory was not empty. It contained rdiff snapshots of files (created with the same backup script) from a previous installation (of F10).
I forgot to make it clear that all succeeding daily backups (since the bug was reported) have been successful.
ok, thats good. I guess I can ask upstream about this error as I can't see whats going on...
Hum. Do you recall what version of rdiff-backup you were using before on F10? Perhaps there was a version change there?
I'm sorry, but I stopped using rdiff-backup and I can't remember the version number.
This message is a reminder that Fedora 11 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 11. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '11'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 11's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 11 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 11 changed to end-of-life (EOL) status on 2010-06-25. Fedora 11 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.