Closed jackmawer closed 1 year ago
However, I wonder if you'd consider writing the .syncrclone directory to the path we are syncing rather than the remote root
This is what is supposed to happen. It shouldn't be writing to the root unless you are using workdirB
(or workdirA
). if those are set to None
(default), then it should be remoteB:.syncrclone
.
You truncated a lot of the log but I think this at the very end when it is trying to save the log, right?
Can you tell me more about your remote? Can you share the config for bx:
(with sensitive info redacted)? Is it a Synology by any chance?
I have a thought as to what may be going on. Let me investigate and I'll report back.
Hi,
I think I found the issue. Can you try to use fix26
python -m pip install git+https://github.com/Jwink3101/syncrclone@fix26
I am not 100% sure if this'll fix it and I can't easily reproduce it on my end but I have an educated guess.
There was a leading /
in setting the workdir path. I think this was completely innocuous most of the time since a/b//c
is the same as a/b/c
and I suspect it got fixed internally.
And on most remotes, X:/path
is the same as X:path
but, looking at the docs:
Note that some SFTP servers will need the leading / - Synology is a good example of this. rsync.net and Hetzner, on the other hand, requires users to OMIT the leading /.
(BTW, I guessed Synology but I had it flipped. Now I am guessing rsync.net or Hetzner)
This bug may also explain why you are seeing .syncrclone
getting written to the wrong place.
WIth that fix, all of my tests but one pass but I think that would fail anyway due to a change in rclone (or something else. I'll look into it later but I wanted to see if this works for you now.)
I merged in the fix and am closing this issue.
First of all, I think that fix was needed either way. It was incorrect being there.
Second, while I haven't heard back, I am 99% sure this will fix it. What you describe, both in terms of the issue and the workaround, is consistent with my fix.
Of course, if this doesn't fix it, please reopen the issue
Hi there,
I bumped into a curious issue while trying to sync with a particularly restrictive SFTP remote. Although the home directory is readable as normal, the root directory
/
returns a permissions error when attempted to be read. It seems that syncrclone causes an issue here, because it doesn't actually just write to .syncrclone in the path specified, but tries to write to the root of the remote from what I understand?The specific issue with this case of using SFTP is of course that this root directory is unreadable and unwriteable so returns confusing SFTP errors:
The workaround in my case was to make an alias remote pointing directly to the SFTP home folder. However, I wonder if you'd consider writing the .syncrclone directory to the path we are syncing rather than the remote root, or otherwise perhaps explain why it is set up this way?
Thanks :)