"C. Michael Pilato" <cmpilato_at_collab.net> writes:
> On 02/24/2014 01:56 PM, Philip Martin wrote:
>> There is a way to create such locks at present: checkout, lock a
>> file, delete the file or parent directory, commit with --no-unlock.
>> We have a regression test for this:
>> lock_tests.py:deleted_path_lock. (Possibly this behaviour could be
>> considered a bug, perhaps 'commit --no-unlock' should remove the
>> locks on deleted files, but implementing that would be hard.)
>
> That behavior *is* a bug that someone must have decided post-facto
> might
> be useful. But hey, I'm not pointing fingers. That approach has
> brought us such awesome features in the past as "file externals".
>
> Oh.
>
> Wait.
It's hard to fix. Commit and unlock are separate filesystem operations
and the server can always die, or fail the unlock, after the commit. I
suppose a new filesystem might have a commit-and-unlock operation but
how could FSFS solve it? We might be able to make FSFS ignore the lock
if the file has been deleted, but that just postpones the problem until
another commit recreates the file.
--
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*
Received on 2014-02-24 20:10:51 CET