Re: new version of glibc xattr patch

[Roland McGrath]

> > I doubt this is true.  If it is, it's a server-side bug.  Note that
> > S_IPTRANS and the gnu.translator xattr are found on nodes opened with
> > O_NOTRANS.  They will more or less never be seen by the file name-based
> > calls, only by f*xattr on an fd opened using O_NOTRANS.  
> 
> I see.  This means existing code will need to get changed or rewritten I
> guess.  Star and {get,set}fattr always use the file name-based calls,
> which is why they do not report passive translators.  We could write a
> {set,show}trans replacement for GNU/Linux perhaps, and add an option to
> GNU tar to not follow translators (along with the other xattr support).
> Star would be a bit more difficult to change, I couldn't get it to use
> O_NOTRANS and f*xattr when I quickly tried, the build system breaks down
> when _GNU_SOURCE is defined.

The other notion that has been suggested in the past is to use some kind of
"notrans translator" for purposes like making backups.  I've always figured
it would be done as an option on the unionfs/shadowfs/fancy-stuff
translator often talked about.  The idea is a translated virtual directory
tree that takes some other directory tree and acts like all or most opens
had the O_NOTRANS flag set.  (The "or most" means to suggest the
possibility of fancier configuration to follow some translators and not
others, i.e. treat a few like traditional "mount points" while treating
most as passive info to be read.)  System-wide backups might use a standard
translator /notrans, or use settrans --chroot to run tar et al.  (To use
such a translator as some process's root node would require the fancier
flavor so that it didn't interfere with /servers and the like.)


Thanks,
Roland