copying a file on a locked file removes the lock on the destination

[individual-it]

Steps to reproduce

1. lock a file
2. copy an other file on the destination of the locked file by supplying the token e.g. curl -u uu1:uu1 -X COPY "http://localhost/owncloud-core/remote.php/dav/files/uu1/textfile2.txt" -H "Destination: http://localhost/owncloud-core/remote.php/dav/files/uu1/textfile1.txt" -v -H "If: (<opaquelocktoken:272a7666-3d64-49ee-a017-14d57572cf72>)"

Expected behaviour

the destination file is still locked

I cannot find the exact scenario in the RFC only:

A COPY method invocation MUST NOT duplicate any write locks active on
the source. However, as previously noted, if the COPY copies the
resource into a collection that is locked with a depth-infinity lock,
then the resource will be added to the lock.

https://tools.ietf.org/html/rfc4918#section-7.6

But I would expect the destination lock still be present

Actual behaviour

destination file is not locked any more

[ownclouders]

GitMate.io thinks the contributor most likely able to help you is @PVince81.

Possibly related issues are #26838 (File locking), #24737 (File Locked), #28991 (file is locked), #17243 (Lock sharing operations when file is locked), and #240 (--- Removed ---).

[davitol]

But I would expect the destination lock still be present

I had already tested this scenario (#34157 (comment)) and from what I understood from the RFC also posted by you in the OP, the lock should not be present in the destination

From the RFC

7.6.  Write Locks and COPY/MOVE

   A COPY method invocation MUST NOT duplicate any write locks active on
   the source.  However, as previously noted, if the COPY copies the
   resource into a collection that is locked with a depth-infinity lock,
   then the resource will be added to the lock.

   A successful MOVE request on a write locked resource MUST NOT move
   the write lock with the resource.  However, if there is an existing
   lock at the destination, the server MUST add the moved resource to
   the destination lock scope.  For example, if the MOVE makes the
   resource a child of a collection that has a depth-infinity lock, then
   the resource will be added to that collection's lock.  Additionally,
   if a resource with a depth-infinity lock is moved to a destination
   that is within the scope of the same lock (e.g., within the URL
   namespace tree covered by the lock), the moved resource will again be
   added to the lock.  In both these examples, as specified in
   Section 7.5, an If header must be submitted containing a lock token
   for both the source and destination.

@individual-it @PVince81