pyOwnCloud icon indicating copy to clipboard operation
pyOwnCloud copied to clipboard

Synching same folder to 2 destination folder deletes files in that folder

Open diederikdehaas opened this issue 11 years ago • 3 comments

When testing the use_limits branch, although I'm quite sure it has nothing to do with that branch, I synced the same folder to 2 different destination folders. When doing the 2nd sync, the source folder's files were deleted.

Reproducibility: always

Steps to reproduce:

  • create 2 (destination) folder in your owncloud folder (test1 and test2 in my case)
  • invoke the sync to the test1 folder and notice that source and destination are (almost) the same Command: time python csync/csync.py --config ../../pyOwncloud/logs.conf --dst=test1 --uploadlimit=1000
Found libocsync @ libocsync.so.0
Syncing /home/diederik/logs to ownclouds://cknowsvr01/owncloud/remote.php/webdav/test1 logging in as user: diederik
ownCloud password:

real    0m37.482s
user    0m1.324s
sys     0m0.136s
  • invoke the sync to the test2 folder and notice that nothing got uploaded and the files in the source folder are gone Command: time python csync/csync.py --config ../../pyOwncloud/logs.conf --dst=test2 --uploadlimit=1000
Found libocsync @ libocsync.so.0
Syncing /home/diederik/logs to ownclouds://cknowsvr01/owncloud/remote.php/webdav/test2 logging in as user: diederik
ownCloud password:

real    0m14.182s
user    0m0.284s
sys     0m0.036s

ls -l before/after 1st run: https://gist.github.com/diederikdehaas/7587395 ls -l after 2nd run: https://gist.github.com/diederikdehaas/7587656 pyOwncloud/logs.conf: https://gist.github.com/diederikdehaas/7587732

diederikdehaas avatar Nov 21 '13 19:11 diederikdehaas

The problem is that there is a sqlite database called ".csync_journal.db", that take care of the sync process. If you sync at the 2nd run to another dst. The db says, ok these files i have seen at the server before but now they are gone at server, and the files localy are at "old version (not changed)", so let's delete them.

To solve this we have to save the last dst in a file and print a warning, if it changes. But actually we should involve upstream.

hefee avatar Nov 21 '13 22:11 hefee

On Thursday 21 November 2013 14:18:03 hefee wrote:

But actually we should involve upstream.

I agree, I'll file the bug there. Shall we ignore this issue for 0.3.1?

diederikdehaas avatar Nov 21 '13 22:11 diederikdehaas

Removed it from issue list for 0.3.1.

hefee avatar Nov 21 '13 22:11 hefee