Bug 486426 - rdiff-backup breaks with new libattr
rdiff-backup breaks with new libattr
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: rdiff-backup (Show other bugs)
10
All Linux
low Severity medium
: ---
: ---
Assigned To: Gavin Henry
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-02-19 13:01 EST by Matt Thompson
Modified: 2009-04-27 17:19 EDT (History)
4 users (show)

See Also:
Fixed In Version: 1.2.8-1.fc9
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-04-27 17:18:50 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Matt Thompson 2009-02-19 13:01:08 EST
Description of problem:

With today's upgrade of libattr (due to bug #485473), something changed with rdiff-backup to kill my rdiff-backup scripts.  Namely, when I try to run the script I get the exception below, and rdiff-backup dies.

According to the rdiff-backup mailing list, the exception "is occurring while updating ACL's, so it's likely that the update to libattr is the cause."  I also note that the backup drive is NTFS-formatted, but it has caused no problems with rdiff-backup until today.

FYI, my backup script looks like (with some identity fudging):

ARCHIVEROOT=/media/LaCie/LinuxBack ;
###########################################
## Home Directory #########################
###########################################
SOURCEDIR=/home/USER/ ;
MOZCACHEDIR=/home/USER/.mozilla/firefox/0pntvzz6.default/Cache/ ;
ARCHIVENAME=COMPUTER-rdiff-backup-home ;
rdiff-backup \
    -v3 \
    --print-statistics \
    --exclude-sockets \
    --exclude $SOURCEDIR"Music/" \
    --exclude $SOURCEDIR"Videos/" \
    --exclude $SOURCEDIR".Trash/" \
    --exclude $MOZCACHEDIR \
    $SOURCEDIR $ARCHIVEROOT/$ARCHIVENAME ;
rdiff-backup --print-statistics --force --remove-older-than 3W $ARCHIVEROOT/$ARCHIVENAME


Version-Release number of selected component (if applicable):
rdiff-backup-1.2.5-1.fc10.x86_64
attr-2.4.43-2.fc10.x86_64

How reproducible:
Always.
  
Actual results:

Exception '[Errno 95] Operation not supported' raised of class '<type 'exceptions.IOError'>':
  File "/usr/lib64/python2.5/site-packages/rdiff_backup/Main.py", line 304, in error_check_Main
    try: Main(arglist)
  File "/usr/lib64/python2.5/site-packages/rdiff_backup/Main.py", line 324, in Main
    take_action(rps)
  File "/usr/lib64/python2.5/site-packages/rdiff_backup/Main.py", line 280, in take_action
    elif action == "backup": Backup(rps[0], rps[1])
  File "/usr/lib64/python2.5/site-packages/rdiff_backup/Main.py", line 337, in Backup
    backup_final_init(rpout)
  File "/usr/lib64/python2.5/site-packages/rdiff_backup/Main.py", line 497, in backup_final_init
    checkdest_if_necessary(rpout)
  File "/usr/lib64/python2.5/site-packages/rdiff_backup/Main.py", line 905, in checkdest_if_necessary
    dest_rp.conn.regress.Regress(dest_rp)
  File "/usr/lib64/python2.5/site-packages/rdiff_backup/regress.py", line 71, in Regress
    for rf in iterate_meta_rfs(mirror_rp, inc_rpath): ITR(rf.index, rf)
  File "/usr/lib64/python2.5/site-packages/rdiff_backup/rorpiter.py", line 281, in __call__
    last_branch.fast_process(*args)
  File "/usr/lib64/python2.5/site-packages/rdiff_backup/regress.py", line 268, in fast_process
    if rf.metadata_rorp.isreg(): self.restore_orig_regfile(rf)
  File "/usr/lib64/python2.5/site-packages/rdiff_backup/regress.py", line 292, in restore_orig_regfile
    rpath.copy_attribs(rf.metadata_rorp, tf)
  File "/usr/lib64/python2.5/site-packages/rdiff_backup/rpath.py", line 190, in copy_attribs
    if Globals.acls_write: rpout.write_acl(rpin.get_acl())
  File "/usr/lib64/python2.5/site-packages/rdiff_backup/rpath.py", line 1336, in write_acl
    acl.write_to_rp(self, map_names)
  File "/usr/lib64/python2.5/site-packages/rdiff_backup/eas_acls.py", line 371, in write_to_rp
    self.default_entry_list, map_names)
  File "/usr/lib64/python2.5/site-packages/rdiff_backup/eas_acls.py", line 380, in set_rp_acl
    acl.applyto(rp.path)

Expected results:

rdiff-backup backups the directory in question.
Comment 1 Kevin Fenzi 2009-02-19 19:30:43 EST
What version of libattr do you have installed? 
Does the 2.4.43-2 version fix things?
Comment 2 Matt Thompson 2009-02-20 07:38:02 EST
Thought I put it up there...hmm.  Well, I have:

attr-2.4.43-2.fc10.x86_64
libattr-devel-2.4.43-2.fc10.x86_64
libattr-2.4.43-2.fc10.i386
libattr-2.4.43-2.fc10.x86_64
libattr-devel-2.4.43-2.fc10.i386

Indeed, I think it was the 2.4.43-2 version that *caused* the break because the problems began occurring after I updated Fedora yesterday.
Comment 3 Kevin Fenzi 2009-02-24 21:29:46 EST
weird. I don't see anything in the changes there that would cause this. :( 

If you revert those packages everything works again as normal?

I'm adding the attr maintainer here to see if he has any ideas...
Comment 4 Matt Thompson 2009-02-25 07:58:29 EST
(In reply to comment #3)
> weird. I don't see anything in the changes there that would cause this. :( 
> 
> If you revert those packages everything works again as normal?
> 
> I'm adding the attr maintainer here to see if he has any ideas...

You are absolutely right, it is *not* due to attr...somehow.  I reverted and no go.  So I tried this:

# rdiff-backup -v3 /etc/ /scratch/trialback

where I'm backing up *not* to my external drive, but to a local disk, and it worked.

Is there something that could have changed how my external NTFS drive was mounted that would kill rdiff-backup?  Because it has worked fine for a over a year until then.
Comment 5 Matt Thompson 2009-02-25 08:28:34 EST
I think I might possibly see the problem.  Previous to that day, I had upgraded NTFS-3G from 2009.1.1 to 2009.2.1.  Then, on the Day of Trouble, I rebooted, which remounted the drive now using 2009.2.1.  If you look at the notes for that package:

STABLE Version 2009.2.1 (February 12, 2009) -- Release Notes 
<snip>
# Change: The user extended attribute namespace is supported by default on Linux. 

and from the release notes:

The user namespace extended attributes are supported from now by default 
on Linux. The other namespaces like system, security, and trusted, are 
supported by the Advanced NTFS-3G driver. Please see more at

    http://pagesperso-orange.fr/b.andre/advanced-ntfs-3g.html
and
    http://pagesperso-orange.fr/b.andre/extend-attr.html

I read this as saying now the default option is "streams_interface=xattr" it seems, and not "streams_interface=none"

So I try:

# mount -t ntfs-3g /dev/sdd1 /media/LaCie -o streams_interface=none

and then a trial:

# rdiff-backup -v3 /etc/ /media/LaCie/trial

Huzzah! It works!

So, is there a setting I should set on rdiff-backup...or one I should set for autofs/fuse/?? (whichever one sets the default mounting during boot up)?
Comment 6 Kevin Fenzi 2009-02-25 13:54:45 EST
You can try running rdiff-backup with '--no-eas' and see if that works?

So, is this a rdiff-backup bug in not handling them right, or a ntfs-3g bug in the way they are implementing it? It's not clear to me which one it is. ;(
Comment 7 Matt Thompson 2009-02-25 14:14:41 EST
I remounted my drive without "streams_interface=none" and then tried:

# rdiff-backup -v3 --no-eas /etc/ /media/LaCie/trial 

That fails.  However, running:

# rdiff-backup -v3 --no-acls /etc/ /media/LaCie/trial 

does work.

I, too, am unsure who is to "blame" here.  My guess is rdiff-backup in the sense that this change is very new and thus needs to be interpreted and included in the code...but this is mighty low-level stuff here.

One question I have with these workaround is *which* is better?  Mounting with "streams_interface=none" or using "--no-acls"?
Comment 8 Szabolcs Szakacsits 2009-02-26 09:59:48 EST
Everything seems to work as expected.

Stable NTFS-3G (not the Advanced one) supports only the User namespace EAs. ACLs are using EAs in the System namespace. This is why --no-acls works. --no-eas failing is unexpected unless it means "all EAs except the ACLs".

"rdiff-backup --no-acls" is better because it will also save User EAs, though you can have the same problems with the Security and Trusted namespace EAs.
Comment 9 Kevin Fenzi 2009-03-08 22:39:13 EDT
ok. So, where are we here?

There is a 1.2.7 now upstream where they say: 

"Don't crash when filesystem can't set ACL. Thanks to Matt Thompson for the bug
report."

Is this the same bug? ;) If so, I can push out a 1.2.7 update...
Comment 10 Matt Thompson 2009-03-09 07:35:28 EDT
Yep! Of course, in that irony that is bugzilla, I can't test to see if it's fixed until the updated RPM is out.  So, please do push the update and I'll test and close this bug.
Comment 11 Kevin Fenzi 2009-03-12 17:16:16 EDT
Sorry for the delay. 

I have wipped up a scratch build for f10 at: 

http://koji.fedoraproject.org/koji/taskinfo?taskID=1238693

Can you test that and confirm the fix?
If it looks ok, I can push out to f9/f10 testing.
Comment 12 Matt Thompson 2009-03-13 07:25:57 EDT
(In reply to comment #11)
> Sorry for the delay. 
> 
> I have wipped up a scratch build for f10 at: 
> 
> http://koji.fedoraproject.org/koji/taskinfo?taskID=1238693
> 
> Can you test that and confirm the fix?
> If it looks ok, I can push out to f9/f10 testing.  

That build does indeed seem to work now when I don't use --no-acls.  It seems to detect the missing ACLs settings...or whatever:

Warning: Access Control List file not found

The only thing I saw was that the package wasn't signed (i.e., 'yum localinstall --nogpgcheck') but that seems to be kind of common with koji packages.

Thanks for the help.  I'd mark this CLOSED, but I'm not too sure on the subfield (NEXTRELEASE? RAWHIDE?).
Comment 13 Fedora Update System 2009-03-14 15:29:33 EDT
rdiff-backup-1.2.7-1.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/rdiff-backup-1.2.7-1.fc10
Comment 14 Fedora Update System 2009-03-14 15:39:07 EDT
rdiff-backup-1.2.7-1.fc9 has been submitted as an update for Fedora 9.
http://admin.fedoraproject.org/updates/rdiff-backup-1.2.7-1.fc9
Comment 15 Kevin Fenzi 2009-03-14 15:40:20 EDT
Well, the updates system will close this once it hits stable, so you can just wait for that... 
:)

I would like to let it sit in testing for a few days at least before pushing it to stable.
Comment 16 Fedora Update System 2009-03-16 15:37:36 EDT
rdiff-backup-1.2.7-1.fc9 has been pushed to the Fedora 9 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing-newkey update rdiff-backup'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2009-2700
Comment 17 Fedora Update System 2009-03-16 15:44:10 EDT
rdiff-backup-1.2.7-1.fc10 has been pushed to the Fedora 10 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update rdiff-backup'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-2721
Comment 18 Fedora Update System 2009-04-08 22:32:02 EDT
rdiff-backup-1.2.8-1.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/rdiff-backup-1.2.8-1.fc10
Comment 19 Fedora Update System 2009-04-08 22:33:15 EDT
rdiff-backup-1.2.8-1.fc9 has been submitted as an update for Fedora 9.
http://admin.fedoraproject.org/updates/rdiff-backup-1.2.8-1.fc9
Comment 20 Fedora Update System 2009-04-09 12:06:57 EDT
rdiff-backup-1.2.8-1.fc9 has been pushed to the Fedora 9 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing-newkey update rdiff-backup'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2009-3429
Comment 21 Fedora Update System 2009-04-09 12:15:19 EDT
rdiff-backup-1.2.8-1.fc10 has been pushed to the Fedora 10 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update rdiff-backup'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-3483
Comment 22 Fedora Update System 2009-04-27 17:18:43 EDT
rdiff-backup-1.2.8-1.fc10 has been pushed to the Fedora 10 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 23 Fedora Update System 2009-04-27 17:19:23 EDT
rdiff-backup-1.2.8-1.fc9 has been pushed to the Fedora 9 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.