repository seemingly corrupted after "abort: Operation not permitted: 'path_to_directory' "

[Becker, Mischa J]

From: j. van den hoff
Sent: Thursday, August 08, 2013 1:29 PM
Subject: Re: repository seemingly corrupted after "abort: Operation not permitted: 'path_to_directory' "

> On Thu, 08 Aug 2013 21:42:34 +0200, Matt Mackall <mpm at selenic.com> wrote:
>> On Thu, 2013-08-08 at 21:21 +0200, j. van den hoff wrote:
>>> "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/pyth
>>> on2.7/site-packages/mercurial/scmutil.py",
>>> line 337, in __call__
>>>      util.unlink(f)
>>> OSError: [Errno 1] Operation not permitted: '/Users/vdh/scripts/util/sd'
>>> abort: Operation not permitted: '/Users/vdh/scripts/util/sd'
>>> 8<-------------------------------------------------------------------
>>> --- the error occuring in `util.unlink' hints at a permission problem
>>> in the working copy, I guess? but the subdirectory in question does
>>> not have any "wrong" permissions.
>>
>> Ahh.
>>
>> a) you're trying to replace a directory with a file of the same name
>
> yes that makes sense: there indeed used to be a file `sd' in the old
> revision which afterwards was renamed to `sd.ksh' and moved to a newly
> created directory `sd' (together with other stuff).
>
>> b) Mercurial is trying to delete the directory with unlink() rather
>> than rmdir()
>> c) you're apparently using OS X, which is based on BSD
>
> indeed. the /Users  and Frameworks stuff gives that away, I guess ...
>
>> d) BSD used to stupidly think that removing a directory with unlink is
>> ok if you're root
>
> you mean "only ok if you're root", is that right? or what is the problem
> here with BSD?
>
>> e) Therefore you get a misleading EPERM (Operation not permitted)
>> rather than EISDIR (Is a directory)
>>
>> Step (b) is perhaps our oldest open bug:
>>
>> http://bz.selenic.com/show_bug.cgi?id=29
>>
>> ..which hasn't really attracted much attention since people don't
>> encounter this much.
>
> well, it happens ;-)
>
>> Moving the directory aside will let you make forward progress.
>
> you mean, starting from tip, renaming it with `hg mv', committing the rename
> and then doing the update to the ancient revision?

I generally do 'hg up null' to take the repository to a state where neither the directory nor file should exist. If the directory contains ignored files and therefore wasn't actually deleted, you can delete/rename it outside of mercurial to move it out of the repository's way before updating to the desired revision.

> another question: apart from the whole transaction failing (and the error
> message being not helpful under macosx), it concerns me that after the
> failure everything seems to be quite thoroughly messed up in assorted parts
> of the working copy (not at all only in the affected directory) and that I
> did not manage to revert to a sane state from there: after the abort `hg'
> believes to still be at tip but reports lots of `M'odified and `!' (missing)
> files with `hg stat'. so, if one is hit by this bug, is there "a way back"?

The quickest way back is 'hg up -C' which does a clean update and discards all uncommitted changes.

> (I can of course clone the repository (which thankfully is indeed not
> corrupted by the abort), but if there where lots of untracked files in the
> original working copy its of course tedious to collect them and put them
> back in place.)

If you don't have one already, I highly recommend finding a folder comparison tool. As a Windows user, Beyond Compare probably saves me at least a couple hours a week.

Mischa

________________________________

This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain information that is confidential and protected by law from unauthorized disclosure. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.