I ran into a similar situation where the TSM client (v5.2.3 at the time)
wouldn't backup/restore the ext3 extended acls on RHEL3.  The problem
turned out to be that the TSM client is looking for libacl.so but
couldn't find it.  It was available as libacl.so.1 (which symlinked to
libacl.so.1.1.0).  By adding a symlink for /lib/libacl.so pointing to
libacl.so.1 I was able to backup and restore files w/extended acls. 

-Ken Mueller


-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Dave Mussulman
Sent: Tuesday, May 29, 2007 3:15 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: ext2 extended file attributes?


One of my users pointed out that ext2 has an extended attribute to tell
dump not to back it up.  He was wondering if TSM honored that setting. I
gave it a try (chattr +d test_file) and then did an incremental backup
of the directory.  TSM seemed to ignore the no_dump bit and backed up
the file, and upon restore, didn't restore the ext2 attributes (they
were all blank.)  Is this expected?  I can understand, perhaps, not
honoring the no_dump (since it's not dump,) but I'm a little concerned
extended file attributes for ext3 aren't backed up/restored.  Is there a
special flag or setting I need to define on the client for that
behavior?  A bug?

This is on a 5.3.3 client on a RedHat AS4 system.

Dave