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

[j. van den hoff]

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/python2.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?

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"?

(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.)

thanks again for the quick feedback and help in sorting this out.

j.

>


-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/