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

[Pierre-Yves David]

nevermind, 755 means read+x now read+write. So this is the issue. 
preparing a patch.

On 5/9/20 8:17 PM, Pierre-Yves David wrote:
> 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