Data loss during cut&paste cross-space

[kulmann]

Steps to reproduce

1. Select any file in your personal space
2. Use ctrl+x (linux/windows) or cmd+x (mac) to cut the file
3. Navigate into a project space
4. Use ctrl+v (linux/windows) or cmd+v (mac) to paste the file

Expected behaviour

a) File gets moved successfully OR b) in case of an error the file stays in the original location

Actual behaviour

Apparently cross-space move (internally: copy & delete) is not possible at all or not correctly implemented in web (needs investigation). The much bigger issue in this case is, that the failing move request fails results in data loss: the file doesn't get copied successfully but gets deleted from the original location anyway.

Needs investigation if the two bugs are backend only, frontend only or a mix of both.

Solution

1. Cross space moves do not work, the fix in reva changes the behavior
   • no data loss
   • Returns 502 Bad Gateway according to spec
2. Web also needs to change the behavior, to not offer MOVE across storage spaces. COPY and DELETE works just fine. @tbsbdr @pmaier1

[kulmann]

Seems to be a backend issue. Web sends the following request for moving a file from a personal space to a project space:

curl 'https://host.docker.internal:9200/remote.php/dav/spaces/1284d238-aa92-42ce-bdc4-0b0000009157%24some-admin-user-id-0000-000000000000/test/test.txt' \
  -X 'MOVE' \
  -H 'Accept: application/json, text/plain, */*' \
  -H 'Authorization: Bearer xxx' \
  -H 'Cache-Control: no-cache' \
  -H 'Connection: keep-alive' \
  -H 'Destination: https://host.docker.internal:9200/remote.php/dav/spaces/1284d238-aa92-42ce-bdc4-0b0000009157%24e2cd4c2c-c7ab-4328-97f5-095df4cb4e50/asdf/test.txt' \
  -H 'OCS-APIREQUEST: true' \
  -H 'Origin: https://host.docker.internal:9200' \
  -H 'Overwrite: F' \
  -H 'Pragma: no-cache' \
  -H 'Referer: https://host.docker.internal:9200/files/spaces/projects/1284d238-aa92-42ce-bdc4-0b0000009157$e2cd4c2c-c7ab-4328-97f5-095df4cb4e50/asdf?sort-by=name&sort-dir=asc&items-per-page=100' \
  -H 'X-Request-ID: f9dfbba4-274d-4534-8caf-77ef58db8358' \
  -H 'X-Requested-With: XMLHttpRequest' \
  --compressed \
  --insecure

which results in a 404. The corresponding COPY request succeeds.

[kulmann]

@micbar what do you think, fix in ocis/reva or temporarily disable in web? As it can result in data loss this is IMO release blocking.

[micbar]

@kulmann I will take a look.

First impression, looks like a backend problem.

[micbar]

Fixed on the backend side, no data loss anymore. Closing.

@kulmann @tbsbdr Please check if we need UX improvements, e.g.

1. hide the other storage spaces in the location picker during MOVE.
   OR
2. Silently transform a cross storagespace MOVE into a COPY&DELETE

[tbsbdr]

2. Silently transform a cross storagespace MOVE into a COPY&DELETE

userfacing crossstorage "move" should be possible - users won't distinguish between a crossstorage and non-crossstorage move I guess (they are used to easily move a file from HDD to a USB stick). The main problem is, that a cross storage move (copy & delete) can take a long time, right? If yes, I'd propose the following:

1. inform the user, ask for confirmation beforehand: like:
   "Change who has access? This item will be visible to everyone who can see [taget-folder-name] You are about to move 35 GB. This will take several minutes. Are you sure you want to proceed? [cancel][proceed]"
2. Show a move progress indicator and an option to cancel if the user realizes that the operation takes too long: 
   "Moving |=====---------------| 25% completed. Cancel will revert your changes. No data will be lost. [Cancel]"

@micbar would that be the right ui-behaviour?