[tahoe-lafs-trac-stream] [tahoe-lafs] #1946: consider removing some st_* fields from metadata

[tahoe-lafs]

#1946: consider removing some st_* fields from metadata
------------------------+-------------------------------
     Reporter:  daira   |      Owner:
         Type:  defect  |     Status:  new
     Priority:  normal  |  Milestone:  soon
    Component:  code    |    Version:  1.9.2
   Resolution:          |   Keywords:  privacy anonymity
Launchpad Bug:          |
------------------------+-------------------------------

Comment (by zooko):

 Replying to [comment:8 elb]:
 >
 > I get that, but I think it neglects the use case where a user really is
 backing up and restoring a particular system.  That's a use case I care
 about.  Now, I don't care if the stored information is a uid or a username
 or gid or group name or what (and the symbolic names may provide some
 measure of robustness to the disassociation you describe, but can't really
 be said to fix the problem), but I do care that the information is stored.

 Maybe that use case is better served by an archive-oriented backup tool
 such as duplicity or duplicati instead of {{{tahoe backup}}}. All of the
 other backup tools that I know of are archive-oriented instead of file-
 oriented. {{{tahoe backup}}}, on the other hand, makes a separate copy of
 each file that it encounters. So there are a bunch of things which
 archivers (including venerable "tar") can handle that {{{tahoe backup}}}
 can't handle, such as symlinks. Traditional backup is better thought of as
 something that you do to a filesystem or at least a subtree, rather than
 to a set of independent files. They also achieve much better efficiency by
 compressing between files and across subsequent versions than {{{tahoe
 backup}}} does, for the same reason -- {{{tahoe backup}}} can't compress
 across files or across subsequent versions of the filesystem, because it
 has to store every file as an independently addressable and accessible
 entity.

 You can use duplicity or duplicati to archive, delta-compress, store
 metadata, etc. and use their tahoe-lafs backends to securely store the
 actual data. That sounds like a good solution for this use case.

 I kind of think that Brian was right to invent {{{tahoe backup}}}, because
 it is cool and useful, but that I was right that it isn't a good solution
 for the "backup a filesystem" use case. Maybe it should be renamed to
 {{{tahoe mirror}}} or {{{tahoe snapshot}}}.

-- 
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1946#comment:14>
tahoe-lafs <https://tahoe-lafs.org>
secure decentralized storage