Moving files causes delete and re-upload with second Folder Sync Conncetion

[Darkexy]

Expected behaviour

In Windows explorer moving a file or folder within a synced directory should be done by an move operation.

Actual behaviour

In one account I have two Folder Sync Conncetions going two different HDDs on my Desktop. The first is older, syncing the root, but not every folder within it. The second is a few days old, syncing one folder within the root to an other hdd, since I ran out of space.

Moving files and folders in the first Folder Sync works totally fine, according to the log.

Moving files and folders in the second Folder Sync causes delete and re-upload unfortunately.

Steps to reproduce

As described and seen in the log, the folder sync on D:/OwnCloud behaves normally, while the folder sync on X: causes a Delete and Re-Upload instead of Move.

Server configuration

Operating system: Raspberry Pi OS on Raspi 4

Web server: Apache 2.4.38-3+deb10u5 armhf

Database: mariadb-server-10.3

PHP version: php7.3/stable,now 7.3.29-1~deb10u1

ownCloud version: latest stable (10.8.0.4)

Storage backend (external storage): External 4TB HDDs

Client configuration

Client version: 2.8.2 (build 4246)

Operating system: Windows 10

OS language: German

Installation path of client: C:\Program Files\ownCloud

NOTE: I found a simular Issue here, but it seems this is fixed: #7838

[TheOneRing]

Sync folder connections are completely independent they just share an account but don't know about the files of other connections.

Detecting changes across sync connections and disks is not possible.

[Darkexy]

That is not what I asked for. I just wanted to illustrate that on the First Connection Moving Files and Folders worked like it should, while on the second Connection it doensn't. Onthe screenshot you can see, I did the exact same steps first on the first connection and then on the second.

To set it straight:

I created a File and a Folder to test on both, the first and on the second conncetion. And I moved the testfile and folder from the first connection only within the first connection and the second testfile and folder only within the second conncetion.

On the first connection it makes the move operation, and the second it doesn't. So there have to be a problem.

[TheOneRing]

Sorry I got your report wrong.
Can you tell me more about X: I assume you are not using virtual files (those are not supported on a drive root)

Is X: normal HDD, are both drives using NTFS?

Besides that I already have an idea what could cause the issue. The sync is using X: without any slash so our code comparing the file locations could have issues with this...

[Darkexy]

No problem, havn't thought about that it could get read wrong.^^

I dont have virtal files, I sync all to the drive. X is an external USB 3.0 HDD. X: uses exFAT, D: uses NTFS.

Would it be possible to fix it in the config file?

[TheOneRing]

So I did some research:
We are using the file id to detect file moves.
On FAT however the id might change:

In the FAT file system, the file ID is generated from the first cluster of the containing directory and the byte offset within the directory of the entry for the file. Some defragmentation products change this byte offset. (Windows in-box defragmentation does not.) Thus, a FAT file ID can change over time. Renaming a file in the FAT file system can also change the file ID, but only if the new file name is longer than the old one.

https://docs.microsoft.com/en-us/windows/win32/api/fileapi/ns-fileapi-by_handle_file_information

[Darkexy]

Okay, that means I need to format it to NTFS and it should work propably?

[TheOneRing]

Yes

[Darkexy]

Okay. Than it seems like I have no choice. :)

Since I need to redownload all the files, I've an other question/problem. I recognized, that the download speed dropped most of the time to under 2MB/s, while downloading the files to X:. My local netwerk uses Gigabit-Ethernet, which makes me suspicious. Is it possible, that this exFAT thing could effect the downloadspeed too?

[TheOneRing]

I'd rather blame the speed on the raspberry pi :)

[Darkexy]

The Raspi4 ha an Gigabit-Ethernet-Port, too. This si the first time that the speed is that slow. Normaly it does load with about 30-40 MB/s. And it does upload with about 20-40 MB/s. Only with this Connection it started to vary a lot with the download. It starts super fast, than go down to super slow. And from time to time it went up to 20 MB/s for a few minutes and then it drops again.

[Darkexy]

Can verify, that format in NTFS works!

[TheOneRing]

Thx, we will update our documentation and maybe also warn when using fat

[github-actions]

This issue was marked stale because it has been open for 30 days with no activity. Remove the stale label or comment or this will be closed in 7 days.