Moving a dehydrated E2E encrypted file to another folder results in this file removed from both the source and destination folders

[allexzander]

How to use GitHub

• Please use the 👍 reaction to show that you are affected by the same issue.
• Please don't comment if you have no relevant information to add. It's just extra noise for everyone subscribed to this issue.
• Subscribe to receive notifications on status change and new comments.

Expected behaviour

Moving a placeholder file should work as expected, similar to how it works when dealing with non-encrypted destination and hydrated file move.

Actual behaviour

When moving an E2E encrypted dehydrated file (placeholder) from one folder to another folder, the file gets removed from the destination folder upon finalizing the sync, while it was also removed from the source folder.

Steps to reproduce

1. Put a file into a local sync folder
2. Move it (either with drag and drop or with Ctrl+X and Ctrl+V) into an encrypted folder
3. The file is removed from the source folder and is also removed from the destination folder when the sync is finished

Client configuration

Client version:

Operating system:

OS language:

Qt version used by client package (Linux only, see also Settings dialog):

Client package (From Nextcloud or distro) (Linux only):

Installation path of client:

Server configuration

Nextcloud version:

Storage backend (external storage):

Logs

Please use Gist (https://gist.github.com/) or a similar code paster for longer
logs.

1. Client logfile:
   Since 3.1: Under the "General" settings, you can click on "Create Debug Archive ..." to pick the location of where the desktop client will export the logs and the database to a zip file.
   On previous releases: Via the command line: nextcloud --logdebug --logwindow or nextcloud --logdebug --logfile log.txt
   (See also https://docs.nextcloud.com/desktop/3.0/troubleshooting.html#log-files)

2. Web server error log:

3. Server logfile: nextcloud log (data/nextcloud.log):

[FlexW]

That's not only related to e2ee. Happens with normal files too.

[biva]

Thanks @FlexW for having identified that this issue is the same as #3434.

In order to complete the information about this issue, this happens also when renaming a file: it disappears if the file is in a virtual folder that is not available locally.

Did you identify where the issue is? It's a critical issue in our understanding.

[biva]

I also see that renaming a file, in a virtual folder which is available locally, leads to the deletion of the original file (including the previous versions) and the creation of a new file with the new name. Is it related to this issue, or is it related to #3311 ? (my desktop client is 3.2.2)

[FlexW]

@biva The issue is definitely bad and we will work on fixing that. No, the second issue that you describe is not related to this issue. Could you open a new issue for this, so we can keep the issues focused.

[biva]

Hi @FlexW thanks, I'll wait to test it when #3311 will be released in the desktop client: if it's not related, I'll open another issue.

[FlexW]

@biva in fact there I realize now that I was maybe wrong because I misread your message. The issue that you linked is probably related to the pull request you mentioned.

[biva]

Understood, thanks :) Did you manage to find a solution for this current bug? #3379 ?