You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
Possibly related issues are #34372 (moving a locked file into a locked folder (providing token) results in conflicting locks), #24737 (File Locked), #26838 (File locking), #28991 (file is locked), and #21881 (File Permanently Locked).
Maybe we can add a afterMethod:MOVE in the "new" PublicDavLocksPlugin (#36402 - pending to be merged) in order to remove the persistent lock there.
Alternatively, we could add the same functionality in the "FilesPlugin" although there isn't anything related to locks there.
Steps to reproduce
Expected behavior
The lock token of the file should not be preserved https://tools.ietf.org/html/rfc4918#page-33:
Actual behavior
Both lock tokens are preserved
@individual-it @PVince81
The text was updated successfully, but these errors were encountered: