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