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

[Pierre-Yves David]

I just had a quick look at the code. The read itself is already protect 
by a try:… except IOError:…

So this must be the write pas. However the write pass an atomic tmp file 
so, the write should be a replacement of the file and the 755 permission 
"should" works for this. I am very curious about that traceback.

On 5/8/20 11:23 PM, Augie Fackler wrote:
> 
> 
>> On May 8, 2020, at 16:49, Alan Mackenzie <acm at muc.de> wrote:
>>
>> Hello, Augie.
>>
>> Sorry it's taken time to reply.  In a fit of madness I'd deleted dirstate
>> from several repositories to save space.  Finding out what I'd done and
>> fixing it (thank goodness for backups) has been a priority the last few
>> days.
>>
>> On Wed, May 06, 2020 at 11:30:36 -0400, Augie Fackler wrote:
>>
>>
>>>> On Apr 29, 2020, at 3:01 AM, Alan Mackenzie <acm at muc.de> wrote:
>>
>>>> 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.
>>
>> Apologies.  It was hg status, not hg log, which gives rise to the
>> problem.
>>
>>> Nothing is corrupt. You’re getting some permission errors, which should
>>> probably be fixed using a sticky bit or something.
>>
>> OK, let's just say the repo became unusable, with no obvious way to fix
>> it.
>>
>>>> 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.
>>
>> As root, I did cd ~acm/cc-mode.hg, and checked that there was no
>> .hg/wcache directory.  Then I did
>>
>>     # hg status --traceback > foo.out 2> foo.err
>>
>> .  There was only the command's output in foo.out and
>>
>>     not trusting file /home/acm/cc-mode.hg/.hg/hgrc from untrusted user acm, group users
>>     not trusting file /home/acm/cc-mode.hg/.hg/hgrc from untrusted user acm, group users
>>
>> in foo.err.  Should --traceback have produced anything more (I'm not
>> familiar with --traceback)?
> 
> I would have expected more output from --traceback in the case where you were getting permission errors. Now that you've got that wcache directory owned by root, can you reproduce the problem as a non-root user?
> 
>>
>> And there is now a .hg/wcache directory owned by root with permissions
>> 755, containing a single file checkisexec owned by root with permissions
>> 711.
>>
>> -- 
>> Alan Mackenzie (Nuremberg, Germany).
> 
> _______________________________________________
> Mercurial mailing list
> Mercurial at mercurial-scm.org
> https://www.mercurial-scm.org/mailman/listinfo/mercurial
> 

-- 
Pierre-Yves David