Folder healthy, but still get 410 Gone #1916
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
2 Participants
Notifications
Due Date
No due date set.
Reference: tahoe-lafs/trac-2024-07-25#1916
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?
I tried to add copy an item to the public folder on the public grid but received an error. I am able to "ls" the directory and when I run "check" it says it is healthy, but when I try to upload it errors out.
Trace from command line:
Improved readability of ticket.
escape "wiki words"
quote literals
Dear PRabahy:
Thank you for reporting this!
This seems like a bug which has pretty bad consequences for availability. It doesn't ring a bell -- I don't remember seeing this sort of misbehavior reported before. Is it consistently reproducible, or does the behavior sometimes vary? Are there any incident report files in the gateway's base directory? Please see wiki/HowToReportABug. Thanks!
The bug was reproducible at the time. I tried the upload several times before I ended up the with trace that I posted above. Unfortunately, I just tried it again and now the "cp" works just fine now.
I don't see any incident reports and have already restarted the node. If it happens again, I will make sure to grab/post a log.
It's quite possible that a modification to the public directory by another gateway resolved whatever condition was causing the modification by PRabahy's gateway to fail. In that case, I'm not very hopeful of finding out what was wrong :-(
Attachment incident-2013-02-12--19-13-04Z-ejgqrja.flog (602105 bytes) added
I think it is happening again. I don't know if this is relevant or not, but I noticed that the node that originally made the directory is offline.
This time, I can do "ls", but "stat" and "cp" are returning 410.
I am trying to run "check --repair" but it appears to have hung for about 10-15 minutes, so I'm not sure if it is stuck.
"check --repair" finally finished. It said that it was successful, but that the directory was still unhealthy (bug?). I then ran "ls" and another "check"
Every time I check, there are 2 storage nodes that appear online (according to the WUI).
Attachment incident-2013-02-12--20-08-28Z-y7lgyki.flog (636848 bytes) added
Good job capturing evidence when the problem recurred, PRabahy!