Moving files causes re-download and lost of shares in client 2.3.1

[kahlertl]

Expected behaviour

If you move a directory with a file manager on the client side, the moved files should not be re-downloaded and shares should be preserved - like in client v2.2.4.

Actual behaviour

After "moved to" event is propagated to the server, the client downloads the moved files from the server. The notification messages says "files ... updated". If the folder is a share or contains shares these shares are lost.

If the directories / files are moved via web interface, everything works correctly.

Cross-checked the issue with client v2.2.4 and everything works as expected.

Steps to reproduce

1. Create test directory with two subdirectories shared and nested together with some dummy files
2. Share one shared subdirectory with some other user
3. Move shared subdirectory into nested on the client side (Ctrl+X or drag'N'drop in nautilus)

Server configuration

Operating system: Ubuntu 14.04.5 LTS

Web server: nginx

Database: PostgreSQL 9.3.16

PHP version: 7.1

ownCloud version: Nextcloud 11.0.2

Storage backend (external storage): local disk only

Client configuration

Client version:

Nextcloud version 2.3.1
Git revision 433ba03a2e092fd8de4d2830fff58f65e602d30a
Using Qt 4.8.7, built against Qt 4.8.7

Operating system: Ubuntu 16.04.2 LTS

OS language: English

Qt version used by client package: Qt 4.8.7

Client package (From ownCloud or distro): nextcloud-client 2.3.1-1.0~xenial1

Installation path of client: /usr/bin/nextcloud

Logs

ownCloud client logwindow

.owncloudsync.log:

Directory renamed:

#=#=#=# Syncrun started 2017-03-31T17:02:52
#=#=#=#=# Propagation starts 2017-03-31T17:02:53 (last step: 544 msec, total: 544 msec)
#=#=#=# Syncrun finished 2017-03-31T17:02:53 (last step: 178 msec, total: 722 msec)
#=#=#=# Syncrun started 2017-03-31T17:03:11
#=#=#=#=# Propagation starts 2017-03-31T17:03:11 (last step: 383 msec, total: 383 msec)
15:03:14||test/shared -> test/nested/shared|INST_RENAME|Up|1490972536|58de6f7884a1a|0|00139835oczoai38sl70|4||201|0|0|||INST_NONE|
||test/nested/shared/A -> test/nested/shared/A|INST_RENAME|Up|1490972512|58de6f6036333|0|00139836oczoai38sl70|4||0|0|1490972509|||INST_NONE|
||test/nested/shared/B.txt -> test/nested/shared/B.txt|INST_RENAME|Up|1490972519|6cbf2ec24bf7a354eacfe805a1ee5773|0|00139838oczoai38sl70|4||0|0|1490972519|||INST_NONE|
||test/nested/shared/C.txt -> test/nested/shared/C.txt|INST_RENAME|Up|1490972531|31dd70916c1fd335ff67f05bce641827|0|00139839oczoai38sl70|4||0|0|1490972531|||INST_NONE|
#=#=#=# Syncrun finished 2017-03-31T17:03:14 (last step: 2734 msec, total: 3116 msec)

Re-download:

#=#=#=# Syncrun started 2017-03-31T17:03:51
#=#=#=#=# Propagation starts 2017-03-31T17:03:52 (last step: 799 msec, total: 799 msec)
15:03:52||test/nested/shared/B.txt|INST_SYNC|Down|1490972592|b341402b2b815dce1600d60f1babe4ac|0|00139842oczoai38sl70|4||0|0|1490972519|||INST_NONE|
15:03:52||test/nested/shared/C.txt|INST_SYNC|Down|1490972593|29c56b41a958f2588780949c8e3fa713|0|00139843oczoai38sl70|4||0|0|1490972531|||INST_NONE|
#=#=#=# Syncrun finished 2017-03-31T17:03:52 (last step: 425 msec, total: 1223 msec)
#=#=#=# Syncrun started 2017-03-31T17:03:54
#=#=#=#=# Propagation starts 2017-03-31T17:03:54 (last step: 205 msec, total: 205 msec)
#=#=#=# Syncrun finished 2017-03-31T17:03:54 (last step: 176 msec, total: 381 msec)

[michaelstingl]

I wasn't able to reproduce with ownCloud client 2.3.1 on Ubuntu 16.04 connected to ownCloud 9.1.4. Could you generate logs as described in the ownCloud client documentation? (https://doc.owncloud.org/desktop/2.3/troubleshooting.html#log-files)

[kahlertl]

@michaelstingl I have uploaded a gist with the complete client logwindow output for the simple test case described above. Thank you for your fast response :)

[michaelstingl]

@SamuAlfageme Could you have a quick look at the client log ?

[SamuAlfageme]

@f3anaro the problem is client 2.3 uses the new chunking algorithm (#4019) if the server announces it. There was an issue on this implementation on the server though; will be fixed by: owncloud/core#27508

[kahlertl]

@SamuAlfageme Thank you for the hint!

[SamuAlfageme]

@f3anaro no problem! You can also set OWNCLOUD_CHUNKING_NG env.var. to continue working as usual with servers with the issue in the new algorithm.

[kahlertl]

@SamuAlfageme Thanks again 😄