Next Steps: CVS Import Bug - Please Respond

[Oproescu Bogdan (KTXA 3)]

   Hello Bernd,  

   Thanks for your message below. My information & responses 
   are next to your questions. 

   Again, the problem persists, so anyone with any clues 
   about this issue please respond. 

   Cheers, Bogdan 

   Bogdan Oproescu   

   CREDIT SUISSE FINANCIAL SERVICES
   Technology & Services
   Advanced Middleware &
   Development Environments KTXA 3 
   Postfach 600
   CH-8070 Zürich
   Tel.: +41 1 334 6846
   Fax.:+41 1 332 8024
   E-Mail: bogdan.oproescu@credit-suisse.ch
   Internet: http://www.credit-suisse.ch/de/index.html

-----Original Message-----
From: Bernd Jendrissek [mailto:berndj@prism.co.za] 
Sent: Wednesday, August 10, 2005 11:10 AM
To: Oproescu Bogdan (KTXA 3)
Cc: 'Jim Hyslop'; 'bug-cvs@nongnu.org'
Subject: Re: Next Steps: CVS Import Bug - Please Respond

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, Aug 10, 2005 at 10:42:59AM +0200, Oproescu Bogdan (KTXA 3) wrote:
>    1. The failures seem to move around at random, but the pattern seems 
>    always to be large .jar files, causing time overlap between 2 or more 
>    parallel CVS Clients into the SAME Module and Repository pair on our 
>    CVS Central Server. Same is true for the import-tag pair on 2 or more 
>    parallel CVS Clients, but I think this is another manifestation of the 
>    first problem, namely that the "cvs import" is not atomic, so 2 or more 
>    parallel CVS Clients will produce this issue, over and over again. 

[Clueless guessing here...]  Are you able to correlate the error
messages with accesses to perhaps the same file from a different client?
If you suspect a race between two rename_file()s, one could well imagine
a first call to succeed, and a subsequent to fail when the source file
is already "renamed away".  ???

        I mentioned earlier that I can correlate the error messages with 
        accesses ( more specifically, "cvs import"s ) to the SAME Module 
        and Repository pair on our CVS Central Server. The question is 
        the following: since "import" is not atomic, there is no lock 
        created for some Module when imported, so another parallel "cvs import"
        on the SAME Module & Repository pair would conceivably corrupt the .jar 
file. 


>    2. Our CVS Central Server is Unix Solaris 8.0: 
> cvsadmin@su64sr20% uname -i -m -p -r -s -v
> SunOS 5.8 Generic_117350-02 sun4u sparc SUNW,Sun-Fire-480R
> cvsadmin@su64sr20% 

Hmm, from the CVS manual ('info cvs', node Error messages):

`cvs [checkout aborted]: cannot rename file FILE to CVS/,,FILE: Invalid
argument'
     This message has been reported as intermittently happening with
     CVS 1.9 on Solaris 2.5.  The cause is unknown; if you know more
     about what causes it, let us know as described in *Note BUGS::.

I wonder if this is related?  Although I think your errno is No such
file or directory (ENOENT), not Invalid argument (EINVAL).

        You may be on to something here, but I'm not sure. My guess 
        is that this CVS/,,FILE is a temporary file created until the 
        "cvs import" completes, and then deleted. Or possibly CVS can't 
        rename because it's waiting for the 1st cvs import operation to 
        rename first, and generates the above error message. 

BTW is your repository on a local disk or on an NFS mount?  (Not sure
it's relevant, maybe it helps someone more clueful.)

        Our data on our CVS Central Server at Credit Suisse is on our SAN
        ( Storage Area Network ), and our CVS Lock Files are stored in 
        /tmp/cvslocks, which greatly improves performance, but I'm not sure 
        if this is relevant to these CVS Bugs. 

>    3. I know you have no obligation to agree to fixing this issue 
>    or to agree to any particular outcome, I am simply asking if you 
>    or anyone else in the CVS Open Source Community can help us to 
>    resolve these 2 CVS Bugs: parallel import-import and import-tag.

No problem; I was just trying to prevent any misunderstanding.  Bear in
mind you may have difficulty getting answers from a group of volunteers
(unless you have paid for support) to questions that indirectly solicit
"obligations".

Good luck.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQFC+cQi/FmLrNfLpjMRAs32AKCUHH5EkgTk+iXn7pLHP4Kcq4TWWQCdFjK+
fGfxqSlSc311BHWWOGTLsbU=
=Rhma
-----END PGP SIGNATURE-----