please do an cvs admin -kb in tools/solenv/unxsoli3/bin/*.

thank you.

The kb flag is also missing on tools/solenv/unxsols3/bin/*

Changed prio to one !

ok, i guess i'll do this one.

forgot to reassign to me

Reassigned to npm. 


Jeremy, 

Please collaborate with Niels for knowledge transfer / organizational learning. 

Please handle CVS issues according to the agreed upon priority!

My understanding is that this has been resolved / fixed. 

If so, 
then please confirm and update issue, 
otherwise please resolve immediately and update issue.

Please handle CVS issues according to the agreed upon priority!

Understood ... and completely agree. 

As this relates to the Application / Infrastructure, 
reassigned to kat 
for ownership 
(to coordinate technical support as required toward resolution). 

Please resolve IMMEDIATELY, 
as this is now URGENT as well as IMPORTANT.

I have ran the commands mentioned in the issue.

Please test, and make sure this solves your problems.
If not please let kat@collab.net know.

I didn't know how to test to see if the new behavior
was correct so I just assume the actions below are correct.

Thanks
Shane
THe output of the commands is below. (ignore the CVS dir warning
I knew that would happen. no biggie)


[root@openoffice bin]# cvs -d /cvs admin -kb *
cvs admin: warning: directory CVS specified in argument
cvs admin: but CVS uses CVS for its own purposes; skipping CVS directory
RCS file: /cvs/tools/solenv/unxsoli3/bin/_dmake,v
done
RCS file: /cvs/tools/solenv/unxsoli3/bin/_make,v
done
RCS file: /cvs/tools/solenv/unxsoli3/bin/_mkout,v
done
RCS file: /cvs/tools/solenv/unxsoli3/bin/build,v
done
RCS file: /cvs/tools/solenv/unxsoli3/bin/checkdll,v
done
RCS file: /cvs/tools/solenv/unxsoli3/bin/copyprj,v
done
RCS file: /cvs/tools/solenv/unxsoli3/bin/cpp.lcc,v
done
RCS file: /cvs/tools/solenv/unxsoli3/bin/deliver,v
done
RCS file: /cvs/tools/solenv/unxsoli3/bin/dmake,v
done
RCS file: /cvs/tools/solenv/unxsoli3/bin/makedepn,v
done
RCS file: /cvs/tools/solenv/unxsoli3/bin/rscdep,v
done
RCS file: /cvs/tools/solenv/unxsoli3/bin/rscpp,v
done
[root@openoffice bin]# ls
CVS     _make   build     copyprj  deliver  makedepn  rscpp
_dmake  _mkout  checkdll  cpp.lcc  dmake    rscdep
[root@openoffice bin]# cd ..
[root@openoffice unxsoli3]# ls
CVS  bin
[root@openoffice unxsoli3]# cd ..
[root@openoffice solenv]# ls
CVS  config  java    src       unxmacxp  unxsoli2  unxsols2  wnti      wntmsci7
bin  inc     macosp  unxlngi3  unxsogs   unxsoli3  unxsols3  wntmsci3  zip
[root@openoffice solenv]# cd unxsol
unxsoli2  unxsoli3  unxsols2  unxsols3  
[root@openoffice solenv]# cd unxsol
unxsoli2  unxsoli3  unxsols2  unxsols3  
[root@openoffice solenv]# cd unxsols3/bin/

[root@openoffice bin]# ls
CVS     _make   build     cpp.lcc  dmake    makedepn  rscpp
_dmake  _mkout  checkdll  deliver  javadep  rscdep
[root@openoffice bin]# cvs -d /cvs admin -kb *
cvs admin: warning: directory CVS specified in argument
cvs admin: but CVS uses CVS for its own purposes; skipping CVS directory
RCS file: /cvs/tools/solenv/unxsols3/bin/_dmake,v
done
RCS file: /cvs/tools/solenv/unxsols3/bin/_make,v
done
RCS file: /cvs/tools/solenv/unxsols3/bin/_mkout,v
done
RCS file: /cvs/tools/solenv/unxsols3/bin/build,v
done
RCS file: /cvs/tools/solenv/unxsols3/bin/checkdll,v
done
RCS file: /cvs/tools/solenv/unxsols3/bin/cpp.lcc,v
done
RCS file: /cvs/tools/solenv/unxsols3/bin/deliver,v
done
RCS file: /cvs/tools/solenv/unxsols3/bin/dmake,v
done
RCS file: /cvs/tools/solenv/unxsols3/bin/javadep,v
done
RCS file: /cvs/tools/solenv/unxsols3/bin/makedepn,v
done
RCS file: /cvs/tools/solenv/unxsols3/bin/rscdep,v
done
RCS file: /cvs/tools/solenv/unxsols3/bin/rscpp,v
done
[root@openoffice bin]# 

Still not working

Please provide further details 
regarding what is still not working.

I am happy to try to get this working for you guys, but you
will need to give me more details to test what isn't working
and how to tell when it is fixed.

I can't fix a problem I can't reproduce.

cut-n-paste a comparision of what isn't working against a
dir which has the needed functionality.

Thanks
Shane

I have repeated Shane's proceedure at anoncvs.openoffice.org, please let me know
if this helps. If not could you please post your errors as Shane has requested.

Thank you
Kat

It adds the -kb option but file is still unusable, pick any executable:
$ file build
build: ELF 32-bit (Éâx?î}H?¿~0`?K\? -(?t? xÿK?L8E?) MSBfile: lseek failed (Inval
id argument).
$ cvs status build
File: build             Status: Up-to-date

   Working revision:    1.2
   Repository revision: 1.2     /cvs/tools/solenv/unxsols3/bin/build,v
   Sticky Tag:          (none)
   Sticky Date:         (none)
   Sticky Options:      -kb

So you are saying that the real problem is that these executables were
checked in with out the -kb switch to indicate they are binary.
And you are trying to use the cvs admin commands to tell
CVS that they really are binary?

ie one approach which (in theory) could work would be to 
cvs remove these, then cvs add -kb  them.  Right?

I am not trying to avoid fixing the problem, I am just trying
to understand the options, and symptoms of the problem.

The RCS docs don't explain what the -kb  option could 
be fixing.....thus another point of confusion.

Here is the excert from the docs.
       -kb    Generate  a binary image of the old keyword string.
              This acts like -ko, except it performs all  working
              file  input  and output in binary mode.  This makes
              little difference on Posix and Unix hosts,  but  on
              DOS-like  hosts  one  should use rcs -i -kb to ini­
              tialize an RCS file intended to be used for  binary
              files.   Also,  on  all hosts, rcsmerge(1) normally
              refuses to merge files when -kb is in effect.

Sorry for having you continually explain your problem, but I still
don't understand what problem the -kb (or lack thereof) is causing.
Running 'file' simply identifies something is wrong with the file.

> So you are saying that the real problem is that these executables were
> checked in without the -kb switch to indicate they are binary.
> And you are trying to use the cvs admin commands to tell
> CVS that they really are binary?
exactly.

> ie one approach which (in theory) could work would be to 
> cvs remove these, then cvs add -kb  them.  Right?
Let's clarify with Martin or Heiner, please.

Thanks for clarifying, Stefan.  I am quite happy to run
any 'cvs admin' commands which you think will help
the situation, but if those don't work then can
someone who has good copies of those files check
them in with 'cvs add -kb'?

I am sure both CollabNet and you guys just want
to get this issue resolved correctly, ASAP.

If there is anything CollabNet can do to help
please let us know.
Thanks
Shane

Shane, Bill, Kathy and Stefan,

I should add some comments here since I was the someone who did the original
faulty check-in ...

CVS handles binary and text files quite different. Text files are written to the
disk via the stdio library which adds on some platforms a CR (carriage return)
to every LF (line feed). On the other hand, CR's will be removed on read from
the disk. This is exact the behavior which is required for source files which
should be regular text files on all platforms. Additionally certain keywords are
substituted in text files on check-out. For instance $Id$ will be replaced with
$Id: epl2x,v 1.5 2001/01/12 17:58:00 hr Exp $.

This behavior is not suitable for binary files. Either one, keyword substitution
or adding/removing CR's will corrupt the binary. To prevent corruption, binary
files have to be added with the -kb flag.

It's easy to forget this flag so it's automatically added for all files with
extensions that guarantee that this file is a binary file: *.gif, *.jpg, *.exe
etc. Files without extensions are considered text files by default, so it's
important to remember to add the -kb flag for UNIX executables which I failed to do.

It's not possible to "cvs remove" the files and than "cvs add -kb" them, because
the old file still exists in the Attic sub directory. The only way to solve the
problem is the following sequence:

1) cvs admin -kb on all corrupted files (this is equivalent to rcs -kb on the
archive files in the repository)
2) Do a fresh checkout of the corrupted files (or add the -kb flag by hand in
the CVS/Entries file)
3) Overwrite the still corrupted files with working binaries and commit.

The first step requires admin access to the repository.

I've now recommited working binaries so this issue is resolved.

Thanks for clarifying, as I had done step #1 on the server, but
I didn't realize that steps 2 and 3 as you have outlined below
were necessary.  Thanks for resolving the issue.

Shane

What I did in the past to fix similar problem is to remove it from RCS
completely and add it using CVS.  Looks like changing the attribute to -kb is
not sufficient.  And removing it using CVS and adding it will fetch it from the
cache and the file will remain a problem.  Maybe you guys have better ways of
fixing it.

Bustamam,

in the past we solved this kinds of problems by manually removing the RCS file
from the repository and add it again, too. This is not possible with OO since
the developers/release engineers don't have direct access to the repository and
someone with administrative access probably not the uncorrupted binary.

Anyway, the three mentioned steps fix these kind of problems and place most of
the work on the someone who made the mistake in the first place :-)

Heiner

verified !