copying a folder within a public link folder to folder with same name as an already existing file overwrites the parent file

[swoichha]

Description

When we copy a folder (e.g testFolder) within a public link folder to a folder which has same name as an already existing file (e.g copy1.txt), then the new copied folder overwrites the previously existing file of same name.

Steps to reproduce

1. Create a user Alice
2. User Alice creates a folder PARENT1
3. User Alice creates another folder PARENT1/testFolder
4. User Alice uploads a file with content some data to PARENT1/testFolder/testfile.txt
5. User Alice uploads a file with content some data 1 to PARENT1/copy1.txt
6. User Alice creates a public link share with path PARENT1 and permissions read,update,create,delete
   [User gets a token in the response eg:zSr0bOKQfLbbv7C]
7. The public copies folder testFolder to copy1.txt using new public webdav api:

curl -X COPY -H "Destination: http://localhost/core/remote.php/dav/public-files/zSr0bOKQfLbbv7C/copy1.txt" 'http://localhost/core/remote.php/dav/public-files/zSr0bOKQfLbbv7C/testFolder' -k -v

Expected behaviour

A 403 Forbidden error

Actual behaviour

 HTTP/1.1 204 No Content
 Date: Mon, 13 Jul 2020 07:59:13 GMT
 Server: Apache/2.4.29 (Ubuntu)
 Set-Cookie: oc7d03sfymph=t3ks17eksv5lbd0k3h6jd3rvhm; path=/core; HttpOnly
 Expires: Thu, 19 Nov 1981 08:52:00 GMT
 Cache-Control: no-store, no-cache, must-revalidate
 Pragma: no-cache
 Set-Cookie: oc_sessionPassphrase=%2Fjnmv9tt3noSLDBwDIXNH9co4VI%2BCcDP2GYor7ez%2FhD96neYW6RAlCPYGm9aCP57k4EfH3D7Sy%2Fc78qPKftCTw%2BA6U9ecjqtoATNbih3ME3oCnrFdSIv9xqPgwE2G444; path=/core; HttpOnly; SameSite=strict
 Content-Security-Policy: default-src 'none';
 X-XSS-Protection: 1; mode=block
 X-Content-Type-Options: nosniff
 X-Frame-Options: SAMEORIGIN
 X-Robots-Tag: none
 X-Download-Options: noopen
 X-Permitted-Cross-Domain-Policies: none

Checking Content

To make sure if the file has been overwritten:

curl -X GET http://localhost/core/remote.php/webdav/PARENT1/copy1.txt/testfile.txt -u alice:1234 -k

some data%  

[phil-davis]

Does this overwriting happen in a user/group share, and for a normal user's files/folders?
(when test scenarios are adding for issue #37669 then this will be known)

I guess that if a user wants to replace a file with a whole folder, or a whole folder with a single file, then that is their business. The server just does what it is told. Or is this strange enough behavior that the server should prevent it?

[individual-it]

I think the current behaviour might be correct. Only if the Overwrite header is set to "F" the overwrite should fail according to the RFC https://tools.ietf.org/html/rfc4918#section-9.8.4

So I interpret that in other cases the destination should be overwritten.