GV

GeezerVison

The World Wide Web, restored to 800 pixels of glory.

Home|About|Gaming cabinet|Archives|How it works|Starter sites

On this site

  • Sign in
  • ActionsCI/CD and automation
  • CodespacesCloud development environments
  • All Features
  • Documentation
  • Training
  • Certifications
  • Build with Copilot
  • Customize Copilot
  • Integrations
  • Trending repos
  • GitHub Sponsors
  • Developer articles
  • Enterprises

This view

  • Original page
  • New address

GeezerVison is showing github.com — Remove the unconditional 5s sleep at the end of moveLink by pwnorbitals · Pull Request #7 · rclone/Proton-API-Bridge

Conversation

@pwnorbitals

@pwnorbitals pwnorbitals commented Aug 24, 2026 •
edited
Loading

Uh oh!

There was an error while loading. Please reload this page.

Copy link
Copy Markdown

moveLink ends with time.Sleep(5 * time.Second) after MoveLink has already returned
successfully. It is unconditional, so every move and rename pays it, and rclone's Proton Drive
backend calls this once per item - a directory move of 100 entries spends over eight minutes
asleep.

The nearest thing to a rationale is the TODO above the call, about cache staleness and a
possible race while a move is in flight. If the sleep is in fact guarding propagation delay
then this PR is wrong and I would rather be told so than guess - but an unconditional wait in
the library is an expensive way to express it, and a retry at the point that reads the moved
link would express it without charging every caller.

"time" was imported for this line alone, so it goes with it.

(obviously Claude Code, but has been under heavy use for more than a week with no visible issue)

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

All reactions
@gama-ci @claude
Remove the unconditional 5s sleep at the end of moveLink
a4a88cd
moveLink ends with time.Sleep(5 * time.Second) after MoveLink has already returned
successfully. It is unconditional, so every move and rename pays it, and rclone's Proton Drive
backend calls this once per item - a directory move of 100 entries spends over eight minutes
asleep.

The nearest thing to a rationale is the TODO above the call, about cache staleness and a
possible race while a move is in flight. If the sleep is in fact guarding propagation delay
then this PR is wrong and I would rather be told so than guess - but an unconditional wait in
the library is an expensive way to express it, and a retry at the point that reads the moved
link would express it without charging every caller.

"time" was imported for this line alone, so it goes with it.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Uh oh!

There was an error while loading. Please reload this page.

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

Uh oh!

There was an error while loading. Please reload this page.

2 participants

@pwnorbitals @gama-ci
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
You are visitor 01402503 — GeezerVison does not store the pages you look up.
Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required.