tahoe backup loops on recursive links #850
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#850
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
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?
Attachment 850-fix-and-test.dpatch (26381 bytes) added
#104 (does cp -r work as expected?) was about this issue as well as a couple of others. Moving the loop issue from #104 to here.
As #641 points out, if we could either skip symlinks or record them as symlinks (instead of following them), this would go away.
Francois: it looks like your patch only catches cycles of length one, right? I.e. if someone did
ln -s .. foo
orln -s ../.. foo
, then "tahoe backup" would still get stuck in a loop, yeah?The more general solution (without fixing #641) would involve keeping a full list of every directory we'd ever started to process, and comparing the target of each symlinky child against that list, and bailing if it was found. That sounds like a lot of memory.
Replying to zooko:
I don't think it's the same issue. This is only about recursive symlinks in the local filesystem.
cp -r
needs to handle loops both in the Tahoe and local filesystems. As Brian says, the only way to do that correctly in general is to keep track of the mutable directory storage indices (for the Tahoe fs) or the inode numbers (for the local fs) that you've already seen.Replying to warner:
Yes, Brian, you're right, this fix is wrong. Can someone with the necessary trac permissions delete this patch from the ticket ?
eh, I think it's fine to leave it there: no harm in having well-labeled experiments lying around :)
I don't know how to fix this in general. I suspect it will require having explicit support for symlinks in tahoe (#641), at least the ability to copy the symlink target name into a tahoe file-like object and then copy it back out again. A short-term fix (again #641, also #729) would be to let you skip over symlinks.. that's what I've been doing for my personal backups.
changeset:e769bbb6dd41d40c fixes this, by skipping over all symlinks (with a warning).