osync icon indicating copy to clipboard operation
osync copied to clipboard

Published 20 hours ago • verified publisher icon deajan

does not sync with a remote source or target (probably due to rsync-3.2.4)

Open luigiannelli opened this issue 2 years ago • 4 comments

Describe the bug does not sync with a remote source or target (probably due to rsync-3.2.4)

To Reproduce Steps to reproduce the behavior:

  • try to sync with a remote source or target having installed rsync-3.2.4

Expected behavior

  • sync

Deviated behavior

  • exits with error rsync: [sender] change_dir "/home/****/'/home/****/targetdirectory/" failed: No such file or directory (2)

Environment (please complete the following information):

  • Full osync version (including build): 1.3.0-dev-rc2 build 2021062901
  • OS: Archlinux
  • Bitness [e.g. x64 or x86]: x64
  • Shell (busybox or else): fish

Additional context downgrading to rsync-3.2.3 solves the problem but be careful, somehow it managed to delete all the files from INITIATOR

luigiannelli avatar May 02 '22 07:05 luigiannelli

I've read about rsync 3.2.4 behavior changes here So far, it seems that some expansion changes were made, except for wildcards. Could you please run export RSYNC_OLD_ARGS=1 before running osync and report back ?

If this resolves the issue, I'll bake in that option as --old-args since osync needs to be compatible with all sorts of rsync versions.

deajan avatar May 05 '22 09:05 deajan

I can confirm that with RSYNC_OLD_ARGS=1 on INITIATOR and with rsync-3.2.4 on both INITIATOR and TARGET, osync works without errors.

luigiannelli avatar May 05 '22 09:05 luigiannelli

Had the same issue and RSYNC_OLD_ARGS helped

andrius avatar Jul 17 '22 08:07 andrius

RSYNC_OPTIONAL_ARGS="--old-args" inside config file stopped with "(ERROR):Cannot copy the deletion list to remote replica". So, "export RSYNC_OLD_ARGS=1" before running "bash ... osync.sh" helped me.

konovalovk avatar Aug 21 '22 20:08 konovalovk

I also experienced the same error on Debian bookworm with local rsync version 3.2.6 protocol version 31, and remote version rsync version 3.2.3 protocol version 31.

After failing RSRYNC_OLD_ARGS=1 properly transferred files, but deleted everything but the .osync_workdir in local repository.

After resetting the directory from a snapshot (I snapshot before and after each rsync), using RSRYNC_OLD_ARGS=1 works flawlessly, so it should be the conjunction of the first failure and the new sync which provoked the unwanted deletion.

I have also noted that adding to my config RSYNC_OPTIONAL_ARGS="--old-args" do not work.

marczz avatar Dec 25 '22 19:12 marczz

Strangely enough, I've encountered this on a very old rsync from RHEL 7 (rsync version 3.1.2 protocol version 31) I've added a general fix for this

deajan avatar Jun 14 '23 12:06 deajan

Note that it is fixed in commit 988009a. The previous 99f107f still lack an export.

May be it would be cleaner in some future release to adopt the new argument quoting, what is your feeling @deajean.

marczz avatar Jun 17 '23 17:06 marczz

Well the thing is that I have no idea how to detect which rsync version is used. RHEL7 being a perfect example of using same rsync version with different arguments.

So in order to maximize compatibility, as long as newer rsync supports old args, I'll stick to them.

Btw, commit that fixed this is https://github.com/deajan/osync/commit/b2f221cb8675e285ed0446313075f02b4df02be6

deajan avatar Jun 19 '23 06:06 deajan