[tahoe-dev] [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 [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.
 >
 > Other than that, xattrs used in that way are a swiss army knife to
 interact with Tahoe-LAFS internals in a FUSEd environment.

 Perhaps, but note that sshfs does not support extended attributes. FUSE-
 via-sshfs is currently the most functional and the best-supported and
 tested FUSE interface to Tahoe.

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