-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consistent failures with recent rclone versions (1.64.2
at least)
#304
Comments
@fenn-cs The latest version of rclone is v1.65.0. Could you please test with that and see if the problem is still present? |
Sure @kfogel |
Issue Update: Rclone Version Compatibility (1.61.0 vs 1.65.0)Overview:I conducted tests by installing Rclone versions 1.61.0 and 1.65.0 on both a local machine and a quick EC2 instance. The objective was to compare download/upload performances for a test development archive. Results Summary:Unfortunately, both versions (1.61.0 and 1.65.0) failed to clone down or upload successfully. Below are the key observations for each version: 1.61.0:
1.65.0:
[Error]: Error reading destination root directory: error listing "". Common Observations:
Conclusion:1.61.0 exhibited some progress in the upload queue, so my suspicion is that 1.65.0 is still not working Next Steps:
|
@fenn-cs Hunh. I agree -- probably a deployment issue, and not anything to do with rclone itself. At the top of this issue, we claim that 1.61.1 works, and it would be very surprising if 1.61.1 would work and yet 1.61.0 would not. Were you testing against the usual dev server? |
@kfogel Yes I used the usual dev server and for the records the last set of load tests that worked on the automated ec2 machines where using 1.61.0.... So there is confirmation that the version I used today has worked in the past. |
@fenn-cs Got it. Looks like this is a deployment issue of some kind. And we need a working dev server anyway, so fixing that comes first! |
Note: @fenn-cs told me that all the results above were obtained with rclone running against a local instance of the service. /CC @slifty |
Yep, against this head of main - sftp-service as well as latest updates done on the back-end and related repositories. (So, all services where at the most recent) |
FYI, @meisekimiu mentioned (in a Slack conversation just now) that she had rclone 1.63.x (most likely 1.63.1-1) working fine against dev SFTP last week, and pointed out that it was unlikely that there is a bug that affects rclone 1.62.x and 1.64.x and yet somehow not 1.63.x. Other people have also reported having rclone (various versions) working against dev. So I'm going to try to reproduce this bug with the latest development version of rclone, built from these instructions. Upstream dev source is currently 1.66-dev, but was recently 1.65. If the latest upstream rclone works against Permanent's dev servers, and I can't reproduce the bug shown here, then I think we can close this ticket. |
After further investigation and discussion, we've decided to close this because we can't reproduce it reliably. Specifically, I was able to download and upload successfully using rclone v1.66-DEV (i.e., unreleased rclone built from upstream source, commit 1ebbc74f1d62). I've attached an annotated transcript here that shows this. @fenn-cs has updated PermanentOrg/sftp-qa-iac#6 accordingly. He also notes:
I too would be interested in the results from that. Here is the transcript of my sessions: 2023-12-07-rclone-1.66-DEV-sessions-with-permanent-prod-transcript.txt |
Expected Behavior
In version 1.64.2, rclone should be able to create new directories in the remote location if they don't already exist.
Actual Behavior
rclone
encounters an error when trying to create new directories. This issue does not occur in version 1.61.1. (and maybe up to1.64.1
/1.63.*
but not tested yet)Sample command
rclone copy -v -P --create-empty-src-dirs ~/permanent-rclone-qa/test-tree/misc/variety/files "dev:/archives/rclone QA 1 (dev) (07av-0000)/My Files/NonExistenFolder"
Logs
Version Information
Additional Context
Perhaps some new flags have been introduced and investigations have to be completed by looking at the change logs.
I suspect #221 is related and that #190 could is made more recurrent.
The text was updated successfully, but these errors were encountered: