"tahoe cp -r --mutable/--immutable": make mutable copy of immutable directories or vice versa #835
Labels
No Label
0.2.0
0.3.0
0.4.0
0.5.0
0.5.1
0.6.0
0.6.1
0.7.0
0.8.0
0.9.0
1.0.0
1.1.0
1.10.0
1.10.1
1.10.2
1.10a2
1.11.0
1.12.0
1.12.1
1.13.0
1.14.0
1.15.0
1.15.1
1.2.0
1.3.0
1.4.1
1.5.0
1.6.0
1.6.1
1.7.0
1.7.1
1.7β
1.8.0
1.8.1
1.8.2
1.8.3
1.8β
1.9.0
1.9.0-s3branch
1.9.0a1
1.9.0a2
1.9.0b1
1.9.1
1.9.2
1.9.2a1
LeastAuthority.com automation
blocker
cannot reproduce
cloud-branch
code
code-dirnodes
code-encoding
code-frontend
code-frontend-cli
code-frontend-ftp-sftp
code-frontend-magic-folder
code-frontend-web
code-mutable
code-network
code-nodeadmin
code-peerselection
code-storage
contrib
critical
defect
dev-infrastructure
documentation
duplicate
enhancement
fixed
invalid
major
minor
n/a
normal
operational
packaging
somebody else's problem
supercritical
task
trivial
unknown
was already fixed
website
wontfix
worksforme
No Milestone
No Assignees
3 Participants
Notifications
Due Date
No due date set.
Reference: tahoe-lafs/trac-2024-07-25#835
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Now that we have immutable directories (#607), we could use some CLI commands to take advantage of them. #828 is about having "tahoe backup" create immutable directories, but what if you want to convert those immutable directories into a form that you can modify again?
tahoe cp
seems like the most appropriate tool.There are a couple of interesting forms of copying that could be done. (In each case, we're talking about directories, and not files.)
The default for
cp -r
should be to use the same type of object: mutable-to-mutable or immutable-to-immutable (and of course, immutable-to-immutable means we just re-use the original dircap).I think that
tahoe cp
should acquire a--mutable
flag which tells it to always create mutable directories, even if the original was immutable. This would be used to convert your "tahoe backup" -created immutable directories into a form that you can modify.Likewise, I think it should have a
--immutable
flag which tells it to always create immutable directories.I think that files should be handled differently: basically the default should be mutable-to-mutable and immutable-gets-shared. If you copy with
--immutable
, then clearly that will trigger mutable-to-immutable (since immutable dirnodes are deep-immutable, so we can't fill them with mutable files). But if you copy with--mutable
, I think we should create mutable dirnodes with immutable files. A separate flag (maybe--mutable-files
) could be used if you really do want to turn all of your immutable files into mutable ones.But if you copy with
--mutable
, I think we should create mutable dirnodes with immutable files. A separate flag (maybe--mutable-files
) could be used if you really do want to turn all of your immutable files into mutable ones.That makes sense to me. But maybe the first option should be
--mutable-dirs
, since it isn't quite the inverse of--immutable
. If you use--mutable
then it should print a help text explaining the difference between--mutable-dirs
and--mutable-files
.This should probably be implemented in terms of #203.
Hm, can we implement this in the next week or so for v1.7? I doubt it, but if someone thinks so then please by all means go ahead!
François Deppierraz indicated an interest in implementing this:
http://tahoe-lafs.org/pipermail/tahoe-dev/2010-July/004833.html
Kevin Reid wrote on tahoe-dev:
As well as the functionality of the proposed
tahoe cp --immutable
, Kevin's post also mentions exclusions, similar totahoe backup
's--exclude*
options I assume. I've filed as #1597 to maketahoe cp
support those options."tahoe cp -r --mutable": make mutable copy of immutable directories, vice versato "tahoe cp -r --mutable/--immutable": make mutable copy of immutable directories or vice versaKevin wrote:
Maybe
tahoe cp -r --immutable srcdir
, with no destination argument, should produce an unlinked tree and output the root cap of that tree.Note that there is no way to implement copying a Tahoe directory structure containing cycles (necessarily with a mutable link somewhere) using
--immutable
. That case should cause an error, and needs a test.amontero asked for this feature (
cp -r --immutable
) on #tahoe-lafs:Replying to daira:
I've opened ticket #2135 with code proposal.