RE: Caused a repository problem, sorry.

RE: Caused a repository problem, sorry.

[Dave Korn]

Dave Korn wrote on 16 June 2008 04:43:


>   It fixed access for me but anon pserver access is playing up: at the
> end of any update it says "cvs update: closing down connection to
> sources.redhat.com" - but only if the -z compression option is used.  

  It also sometimes says

cvs update: closing down connection to cygwin.com: No such file or directory

which suggests it's a perms problem; the fact that it only happens via anon
pserver but not when I use ext ssh access suggests likewise; the way we get
this problem with -z but not -z0 is probably the cvs server truncating the
compressed transmission with an uncompressed error or informational message
right as the very last thing it does at the end of the transaction.

  Where does the history file live?


    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....

Re: Caused a repository problem, sorry.

[Ian Lance Taylor]

"Dave Korn" <dave.korn@artimi.com> writes:

> Dave Korn wrote on 16 June 2008 04:43:
>
>
>>   It fixed access for me but anon pserver access is playing up: at the
>> end of any update it says "cvs update: closing down connection to
>> sources.redhat.com" - but only if the -z compression option is used.  
>
>   It also sometimes says
>
> cvs update: closing down connection to cygwin.com: No such file or directory

I was able to do 
    cvs -z 9 -d :pserver:anoncvs@cygwin.com:/cvs/src co winsup
with no obvious problem.

What command are you running that fails?

>   Where does the history file live?

/cvs/src/CVSROOT/history

Ian

RE: Caused a repository problem, sorry.

[Dave Korn]

Christopher Faylor wrote on 16 June 2008 17:55:

>>  It fixed access for me but anon pserver access is playing up: at the end
>> of any update it says "cvs update: closing down connection to
>> sources.redhat.com" - but only if the -z compression option is used.

> I changed the ownership of all of the files to anoncvs.  I didn't try
> before but I have no problems checking out from cygwin-apps now.

  And ILT couldn't reproduce it, and it WFM on a linux host, and there
haven't been any other complaints on any of the lists.  Can I infer you were
probably using a linux client when you tested it just now as well?

  I think I maybe just ran into a cygwin pipes-vs-eof sort of issue that was
already there but I hadn't seen before.  (I haven't used non-ssh access to
src in many many dll revisions.)

  So I reckon that was probably a false alarm.  I'm not even sure the
fileattrs ownership matters anymore either, just that the contents need to
be zapped and regenerated correctly.  The change of ownership appears not to
have side-effects once we discount the cygwin cvs client eof error message.

  I think this situation arises from some combination of importing and
merging.  At some point in the near future when I backport the work I'm
currently doing from the private branch to the release branch, it may well
happen again; if so, I'll be watching out for it and just repeat the ": >"
trick, since it appears that successfully got the repository running.


  Does anyone on this list actually know for a fact that cvs has been
configured so that anoncvs doesn't need to be the owner of the fileattr
files but can get read access by group privs?  The post I quoted upthread
from 2004 suggested this was critical, but some of those fileattrs had had
the "wrong" ownership for quite some time and nobody noticed.

    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....

Re: Caused a repository problem, sorry.

[Christopher Faylor]

On Mon, Jun 16, 2008 at 04:43:15AM +0100, Dave Korn wrote:
>
>  I was doing a merge into the /cvs/cygwin-apps repository somehow and ran
>into the old "[update aborted]: branch attribute does not match file" error
>that we've occasionally had before.  I don't remember ctrl-c'ing anything.
>
>  I followed the procedure described at 
>http://gcc.gnu.org/ml/gcc/2004-10/msg00369.html
>and truncated the CVS/fileattr files using ": >" to avoid changing
>ownership, but they were already all owned by my uid rather than anoncvs as
>that post suggests before I could even try that.
>
>  It fixed access for me but anon pserver access is playing up: at the end
>of any update it says "cvs update: closing down connection to
>sources.redhat.com" - but only if the -z compression option is used.
>
>  I noticed a few other fileattrs in the repository that aren't owned by
>anoncvs and they don't seem to be causing any trouble.  The ones I truncated
>are regenerating as expected, but still have my uid on them.  (Briefly
>moving one aside broke anon access altogether with a cannot-write-to-file
>error message, so I put it back; I conclude that anoncvs has group write
>perms to get to the fileattr anyway and the whole owner uid issue may no
>longer be a problem since the post I referenced above).
>
>  Uhh, sorry about this.  I didn't do anything out of the ordinary at the
>client end, just your usual cvs up with -j options and commit, so I don't
>know what's happened.  It's only anonymous cvs access using -z that's acting
>funny.

I changed the ownership of all of the files to anoncvs.  I didn't try before
but I have no problems checking out from cygwin-apps now.

cgf

RE: Caused a repository problem, sorry.

[Dave Korn]

Dave Korn wrote on 16 June 2008 05:18:

> Dave Korn wrote on 16 June 2008 04:43:
> 
> 
>>   It fixed access for me but anon pserver access is playing up: at the
>> end of any update it says "cvs update: closing down connection to
>> sources.redhat.com" - but only if the -z compression option is used.
> 
>   It also sometimes says
> 
> cvs update: closing down connection to cygwin.com: No such file or
> directory 

  And sometimes

/tmp/bokr/src $ cvs up
cvs update: closing down connection to cygwin.com: Transport endpoint is not
connected



  Ian: I see your reply in the archive but it hasn't reached me by SMTP yet.

  I've just cut and pasted the exact commandline from your email into three
different machines at two different sites and it appears to happen with the
cygwin version of cvs client 1.11.22, but not with a linux client at
1.11.17.  The end of the checkout on both cygwin machines reads:


U src/include/opcode/tic30.h
U src/include/opcode/tic4x.h
U src/include/opcode/tic54x.h
U src/include/opcode/tic80.h
U src/include/opcode/v850.h
U src/include/opcode/vax.h
cvs checkout: Updating src/include/regs
cvs checkout: closing down connection to cygwin.com: No such file or
directory
/tmp/bork $


  The perms on the history file seem normal.

    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....

Caused a repository problem, sorry.

[Dave Korn]

  I was doing a merge into the /cvs/cygwin-apps repository somehow and ran
into the old "[update aborted]: branch attribute does not match file" error
that we've occasionally had before.  I don't remember ctrl-c'ing anything.

  I followed the procedure described at 
http://gcc.gnu.org/ml/gcc/2004-10/msg00369.html
and truncated the CVS/fileattr files using ": >" to avoid changing
ownership, but they were already all owned by my uid rather than anoncvs as
that post suggests before I could even try that.

  It fixed access for me but anon pserver access is playing up: at the end
of any update it says "cvs update: closing down connection to
sources.redhat.com" - but only if the -z compression option is used.

  I noticed a few other fileattrs in the repository that aren't owned by
anoncvs and they don't seem to be causing any trouble.  The ones I truncated
are regenerating as expected, but still have my uid on them.  (Briefly
moving one aside broke anon access altogether with a cannot-write-to-file
error message, so I put it back; I conclude that anoncvs has group write
perms to get to the fileattr anyway and the whole owner uid issue may no
longer be a problem since the post I referenced above).

  Uhh, sorry about this.  I didn't do anything out of the ordinary at the
client end, just your usual cvs up with -j options and commit, so I don't
know what's happened.  It's only anonymous cvs access using -z that's acting
funny.


    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....