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

[Augie Fackler]

Thanks!

On Sat, May 9, 2020 at 2:19 PM Pierre-Yves David
<pierre-yves.david at ens-lyon.org> wrote:
>
> 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