owncloud / owncloud/ocis

WebDAV COPY fails with status 500 when files or folders are deleted from SRC

Open
#10,400 0 comments 0 reactions 0 assignees View on GitHub
Priority:p3-medium Type:Bug
Dominant language
Go
Stars
2.1k
Forks
274
Avg merge
2d 2h
Merged PRs (30d)
106

Description

## Describe the bug

When files or folders are deleted from the source during a WebDAV COPY operation the COPY is aborted with a 500 status.

## Steps to reproduce
1. Create a simple folder `test` in the root of a space
2. Create two folders `one` and `two` inside test
3. Upload 1000 files to folder `one` and folder `two`
4. Copy folder `test` to a different space
5. Remove folder `two` from `test` on the initial space
6. After some time the COPY will fail with a status 500 and no further information

## Expected behavior
The server should complete the COPY as far as possible and return a 207 Multistatus response as outlined in the spec http://webdav.org/specs/rfc4918.html#METHOD_COPY:

> So, for example, if an infinite-depth copy operation is performed on collection /a/, which contains collections /a/b/ and /a/c/, and an error occurs copying /a/b/, an attempt should still be made to copy /a/c/. Similarly, after encountering an error copying a non-collection resource as part of an infinite-depth copy, the server SHOULD try to finish as much of the original copy operation as possible.
>
> If an error in executing the COPY method occurs with a resource other than the resource identified in the Request-URI, then the response MUST be a 207 (Multi-Status), and the URL of the resource causing the failure MUST appear with the specific error.

## Actual behavior
COPY fails with status 500

Contributor guide

Open the contributing guide

Research direction

Start by reproducing the WebDAV COPY scenario with a large source tree and deleting a source folder during the copy, then read the RFC 4918 COPY requirements linked in the issue. Done means the operation continues where possible and returns a 207 Multi-Status identifying any resource-level failure instead of a generic 500 response.

Written by the indexing model from the issue text.

Assessment

Tech stack
go
Domain
backend
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.