[tahoe-lafs-trac-stream] [tahoe-lafs] #1351: Use extended attributes to expose metadata

[tahoe-lafs]

#1351: Use extended attributes to expose metadata
-----------------------------+----------------------------------------------
     Reporter:  ScottD       |       Owner:  somebody                    
         Type:  enhancement  |      Status:  new                         
     Priority:  minor        |   Milestone:  undecided                   
    Component:  code         |     Version:  1.8.2                       
   Resolution:               |    Keywords:  fuse metadata unix usability
Launchpad Bug:               |  
-----------------------------+----------------------------------------------

Comment (by davidsarah):

 Replying to [comment:1 davidsarah]:
 > Replying to [ticket:1351 ScottD]:
 > > {{{
 > > % getfattr -n readcap /mnt/pubgrid
 > > # file: /mnt/pubgrid
 > > readcap="URI:DIR2-RO:xxx...:yyy..."
 > > }}}
 > >
 > > At the moment, Tahoe does not support storing extended attributes, so
 there are no conflicts. However, ticket:947 proposes to add support for
 storing extended attributes to Tahoe, which would create a namespace
 conflict for this enhancement. Despite that, we could reserve a prefix for
 attributes (e.g., "`tahoe.readcap`") and raise an error/warning when such
 an attribute is asked to be stored.
 >
 > Jan-Benedict Glaw wrote on tahoe-dev:
 > > Well, maybe even storing a cap is useful! After all, it would be kind
 of a combined link/rename operation for some unrelated file/directory.

 On closer examination this isn't a good idea. The problem is that copying
 with preservation of attributes, for example using
 [http://www.gnu.org/software/coreutils/manual/html_node/cp-invocation.html
 cp --preserve=xattr] on Linux, would cause the destination of the copy to
 be aliased to the source. That is harmless for immutable files on the same
 grid (because the source and destination would already have converged),
 but very wrong for mutable files and directories. For immutable
 directories on the same grid it is more subtly wrong: a recursive copy of
 an immutable directory would create a mutable copy, then discard it and
 make the destination point to the original, resulting in a space leak at
 best (which would be temporary when GC is used, but still undesirable), or
 loss of data if the destination already existed. For immutable
 files/directories on different grids (e.g. under different mount points),
 it is also wrong because the source cap won't be valid for the
 destination.

 Preservation of extended attributes is the ''default'' behaviour for
 [http://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man1/cp.1.html
 cp on Mac OS X].

-- 
Ticket URL: <http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1351#comment:2>
tahoe-lafs <http://tahoe-lafs.org>
secure decentralized storage