hg 5.2.2: abort: Permission denied: '..../.hg/wcache/.manifestfulltextcache-gc3hkx8o~'

Pierre-Yves David pierre-yves.david at ens-lyon.org
Wed May 6 16:05:03 UTC 2020



On 5/6/20 5:30 PM, Augie Fackler wrote:
> 
> 
>> On Apr 29, 2020, at 3:01 AM, Alan Mackenzie <acm at muc.de> wrote:
>>
>> Hello again, Augie.
>>
>> On Thu, Apr 02, 2020 at 16:14:48 -0400, Augie Fackler wrote:
>>> It looks like someone did something to that repo as root, and that was
>>> the first time hg sniffed some of the disk contents. It's safe to blow
>>> away the entire .hg/wcache directory, and hopefully that'll have you on
>>> your way.
>>
>> I've worked out what it is.  It is the hg log that my regular backup
>> script does as root.  This wcache directory keeps coming back.
>>
>> hg log, even as root, should surely not corrupt a repository.  It is
>> doing so here.
> 
> Nothing is corrupt. You’re getting some permission errors, which should probably be fixed using a sticky bit or something.

I am not sure we will be able to fix the permission issues, it seems to 
a be ownership issue and as far as I know we don't inherit ownership 
when creating files (because we can't except in the root special case)

>> Now that I know what it is, I can implement workarounds.  But this is
>> ugly; it would be nice if it could be fixed properly.
> 
> Can you reproduce this and add --traceback to the command? I’d be happy to try and patch hg so this doesn’t happen (we shouldn’t choke on permission errors when trying to read/write cache	files), but also know that this isn’t corruption - no data is at risk.

We definitly should not choke on this. This is a cache, so if we can't 
read it, we should treat it as empty, and if we can't write it, we 
should not error out. However issue "ui.log()" call is useful to debug 
slowness.

-- 
Pierre-Yves David



More information about the Mercurial mailing list