2014-01-21 16:04 AEST by Arthur Barrett - Checkout a binary file (eg: a PICT image) from a repository to a mac and you get this error message.


ivybridge-3:Documents abarrett$ cvs -d :ext:scott@172.16.20.43:/myrepo co -d co-medicalobjects-6 
sample
scott@172.16.20.43's password: 
cvs server: Updating co-medicalobjects-6
U co-medicalobjects-6/logo.pct
cvs [checkout aborted]: Internal error: cvs_hqx.cpp, 497: Unknown error: -50



The file status is 'b' (binary) and the rlog is OK.

The checkout directory will contain _new_logo.pct (new_filename.ext) that is in BinHex format but cannot 
be decoded.

2014-01-21 16:07 AEST by Arthur Barrett - Created an attachment (id=2681)
python script for decoding binhex

If you use an alternative bin hex decoder it also gives an error:

ivybridge-3:Documents abarrett$ binhex decode co-medicalobjects-6/_new_logo.pct

binhex: unable to decode 11390 bytes at offset 11390 from "_new_logo.pct" (22 -
Invalid argument).



or


ivybridge-3:Documents abarrett$ python ./binhex-example-1.py
Traceback (most recent call last):
  File "./binhex-example-1.py", line 6, in <module>
    binhex.hexbin(infile, "co-medicalobjects-5/logo-hexbin.pct")
  File
"/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/binhex.py",
line 474, in hexbin
  File
"/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/binhex.py",
line 393, in __init__
  File
"/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/binhex.py",
line 414, in _readheader
  File
"/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/binhex.py",
line 407, in _checkcrc
binhex.Error: CRC error, computed c9f7, read f7c9



The python decoder is particularly helpful because it shows that the checksum
is inverted.  This suggests the problem is byte order issue.

2014-01-21 16:32 AEST by Arthur Barrett - See this document in the MacCVS X source code for an explanation of the binhex 
history:http://cvsgui.cvs.sourceforge.net/viewvc/cvsgui/cvsgui/cvs-1.10/macho/README.txt?
hideattic=0&revision=1.1.4.2&view=markup

2014-01-21 16:35 AEST by Arthur Barrett - because of potential endian issues (byte order issues) I'm making this related to bug 6277 which was also 
a byte order issue.

2014-01-21 16:42 AEST by Arthur Barrett - The README.txt from the MacCVS X project states that:


     MacCvs and MacCvsPro are using an encoding for the macintosh files with
     a resource fork (either using the HQX or AppleSingle file format).
     These files get encoded on the server and are decoded on the client.

If this is literally true (the BinHex) encoding occurs on the server side, but is unencoded on the client side 
and the code does not correctly account for the endian-ness of the CPU then this error (binhex decode 
failure) could occur easily.

2014-01-21 17:03 AEST by Arthur Barrett - Customer suggestion is to have an option which disables the automatic decode.

This could be implemented as a condition on the call to mac_decode_file() in client.cpp or as a condition 
in mac_convert_file() from cvs_hqx.cpp (better option).

However this is not consistent with behaviour elsewhere in CVSNT.  The file has not finished successfully 
checking out.  i.e.: when the file was checked in it contained two forks, but now there is 'just' a binhex 
file.  This is the equivalent of CHKOUTCVS on AS/400 not updating the library (but the temporary file still 
existing in IFS).  This is always an error condition.  The untranslated file is left in _new_filename.ext, but it 
is unusable.

If this is a common problem then some type of --ignore-hqx-errors may be a sensible command line 
option (e.g.: delete the temporary file and continue checkout) so that the bulk of the checkout can 
continue.  A later 'update' will show that the HQX encoded file(s) have not been checked out.

2014-01-21 17:53 AEST by Arthur Barrett - Note: the maccvs x docs are in fact wrong, the encoding does NOT happen server side, but client side 
because mac_convert_file() is only called from client.cpp

I have tested CVSNT client 2.5.03.2382 (part of maccvsx 3.3 beta 2) on powerpc and it will also not 
decode this file.

I suspect that the binhex encoding was done using a 3rd party library  (maccvs x 3.1?) which had a bug in 
it.  Therefore this problem is only likely to strike a few cases where an invalid binhex encoder was used…

it would be nice if CVSNT clients automatically set a revision level 'property' when the file has been binhex 
encoded stating some information about it, e.g.: the version of the client…