[
https://issues.apache.org/jira/browse/SVN-3534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Foad updated SVN-3534:
-----------------------------
Component/s: (was: src)
> Failed ra_neon commit without --no-unlock results in dead lock token.
> ---------------------------------------------------------------------
>
> Key: SVN-3534
> URL: https://issues.apache.org/jira/browse/SVN-3534
> Project: Subversion
> Issue Type: Bug
> Affects Versions: 1.6.x
> Reporter: C. Michael Pilato
> Priority: Major
> Fix For: unscheduled
>
>
> {noformat:nopanel=true}
> Some time ago I noticed this code in libsvn_ra_neon/commit.c's
> commit_delete_entry():
> [...]
> /* dav_method_delete() always calls dav_unlock(), but if the svn
> client passed --no-unlock to 'svn commit', then we need to send a
> header which prevents mod_dav_svn from actually doing the unlock. */
> if (parent->cc->keep_locks)
> {
> if (! extra_headers)
> extra_headers = apr_hash_make(pool);
> apr_hash_set(extra_headers, SVN_DAV_OPTIONS_HEADER,
> APR_HASH_KEY_STRING, SVN_DAV_OPTION_KEEP_LOCKS);
> }
> [...]
> This got me thinking, "If dav_method_delete() always removes locks, what
> happens
> if the commit of a deleted, locked file fails just before completion?" Well,
> exactly what I expected would happen does, in fact, happen. If, say, the
> pre-commit hook script denies the commit, mod_dav will have already removed
> the
> lock from the file. The failed commit will of course result in no new
> revision,
> and thus no actual deletion of the file. But locks aren't time-safe, and the
> lock on the would-be-deleted file is gone forever. Moreover, the Subversion
> client won't realize that the lock has been deleted, and will continue to
> persist the now-dead lock token in the working copy.
> See http://svn.haxx.se/dev/archive-2009-09/0256.shtml for details and a
> reproduction recipe.
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
