moving a locked file into a locked folder (providing token) results in conflicting locks

[individual-it]

Steps to reproduce

1. lock a folder exclusive
2. lock file exclusive
3. move file into folder giving both lock tokens
   e.g curl -u uu1:uu1 -X MOVE "http://localhost/owncloud-core/remote.php/dav/files/uu1/textfile0.txt" -H "Destination: http://localhost/owncloud-core/remote.php/dav/files/uu1/FOLDER/textfile0.txt" -H "If: (<opaquelocktoken:token-of-file>) (<opaquelocktoken:token-of-folder>)"

Expected behaviour

moving should not work
RFC says https://tools.ietf.org/html/rfc4918#section-6.1 :

   4.  For a collection that is locked with a depth-infinity lock L, all
       member resources are indirectly locked.  Changes in membership of
       such a collection affect the set of indirectly locked resources:

       *  If a member resource is added to the collection, the new
          member resource MUST NOT already have a conflicting lock,
          because the new resource MUST become indirectly locked by L.

Actual behaviour

moving is possible and results in multiple exclusive locks for the file

curl -u uu1:uu1 -X PROPFIND http://localhost/owncloud-core/remote.php/webdav/FOLDER/textfile0.txt  -d "<?xml version='1.0' encoding='UTF-8'?> <d:propfind xmlns:d='DAV:'> <d:prop><d:lockdiscovery/></d:prop> </d:propfind>" | xmllint --format -


<?xml version="1.0"?>
<d:multistatus xmlns:d="DAV:" xmlns:s="http://sabredav.org/ns" xmlns:oc="http://owncloud.org/ns">
  <d:response>
    <d:href>/owncloud-core/remote.php/webdav/FOLDER/textfile0.txt</d:href>
    <d:propstat>
      <d:prop>
        <d:lockdiscovery>
          <d:activelock>
            <d:lockscope>
              <d:exclusive/>
            </d:lockscope>
            <d:locktype>
              <d:write/>
            </d:locktype>
            <d:lockroot>
              <d:href>/owncloud-core/remote.php/webdav/FOLDER</d:href>
            </d:lockroot>
            <d:depth>infinity</d:depth>
            <d:timeout>Second-1748</d:timeout>
            <d:locktoken>
              <d:href>opaquelocktoken:0580ee97-344d-4ceb-8b2a-90e0dc58c9f3</d:href>
            </d:locktoken>
            <d:owner>uu1</d:owner>
          </d:activelock>
          <d:activelock>
            <d:lockscope>
              <d:exclusive/>
            </d:lockscope>
            <d:locktype>
              <d:write/>
            </d:locktype>
            <d:lockroot>
              <d:href>/owncloud-core/remote.php/webdav/FOLDER/textfile0.txt</d:href>
            </d:lockroot>
            <d:depth>infinity</d:depth>
            <d:timeout>Second-1732</d:timeout>
            <d:locktoken>
              <d:href>opaquelocktoken:049274dc-7208-428d-a009-05e50cc25d52</d:href>
            </d:locktoken>
            <d:owner>uu1</d:owner>
          </d:activelock>
        </d:lockdiscovery>
      </d:prop>
      <d:status>HTTP/1.1 200 OK</d:status>
    </d:propstat>
  </d:response>
</d:multistatus>

[ownclouders]

GitMate.io thinks possibly related issues are #26838 (File locking), #24737 (File Locked), #8056 (Conflicting Files), #15122 (File & Folder locking ), and #34338 (share receiver can rename a file in a locked folder by using the lock token of the owner).

[individual-it]

possible similar cause like #34358

[PVince81]

moving to backlog, not critical as about folder locks