Thu, 02/03/2000 - 19:03
Forums:
There is a problem untaring the archive sourceModelingAlgorithms-3.0PR2.tar using Sun tar.
x CAS3.0/drv/IntPatch/IntPatch_TheIWLineOfTheIWalkingOfTheIPIntOfIntersection_0.cxx, 3899 bytes, 8 tape blocks tar: directory checksum error
Using another tar (gnu or on another platform) cures the problem.
Fri, 02/04/2000 - 12:19
Hello.
You wrote:
> There is a problem untaring the archive sourceModelingAlgorithms-3.0PR2.tar using Sun tar.
> CAS3.0/drv/IntPatch/IntPatch_TheIWLineOfTheIWalkingOfTheIPIntOfIntersection_0.cxx,
It's not the first time I encounter such problem on Sun. This is probably due to the length of the filename.
Can you check the version of SunOS ?
Be caution, ftp and ar may have the same behaviour !
Regis Le Boite
Fri, 02/04/2000 - 18:10
Hi
I am reposting my earlier message about untar problems on Sun and missing files here. The long file names may be the cause, but even if it untars succesfully, I cannot retrieve all the files from the tar files.
--------------------------------------------------
Hi
I agree that some source files are missing. On the Suns I tried to untar the sourceModelingAlgorithms-3.0.PR2.tar file and it gave me a checksum error. I downloaded it several times from the US HTTP site and once from the ftp site at France (at an agonizing 0.29 kB/s). Both times I got this error. I then untarred the file on SGI which didn't complain - so I thought the tar program on the Suns was not working right. Another thing I noticed was that the 4.0 MB tar.gz file uncompresses to a 37191680 byte file - that is odd, although not impossible, I think.
However when I tried to compile the ModelingAlgorithms component, the script could not find several files in the drv/Geom2dInt, drv/TopOpBRepApprox directories.
This leads me to believe that the tar files are missing some source files.
Rao
--------------------------------------------------
To verify this can the developers check the sourceModelingAlgorithms-3.0.PR2.tar file to check if the following files are present. If they are present, and the long file names is the trouble perhaps the file name (not the subroutine name) can be shortened? In my honest opinion (don't mean it as a criticism), such a long name becomes as hard to understand as an extremely short cryptic name.
CAS3.0/drv/Geom2dInt/Geom2dInt_SequenceNodeOfSeqPCOfPCLocFOfTheLocateExtPCOfTheProjPCurOfGInter_0.cxx
CAS3.0/drv/IntPatch/IntPatch_SequenceNodeOfSequenceOfIWLineOfTheIWalkingOfTheIPIntOfIntersection_0.cxx
CAS3.0/drv/TopOpeBRepApprox/TopOpeBRepApprox_TheFunctionOfTheInt2SOfThePrmPrmSvSurfacesOfApprox_0.cxx
CAS3.0/drv/TopOpeBRepApprox/TopOpeBRepApprox_BSpParLeastSquareOfMyBSplGradientOfTheComputeLineOfApprox_0.cxx
CAS3.0/drv/TopOpeBRepApprox/TopOpeBRepApprox_BSpParFunctionOfMyBSplGradientOfTheComputeLineOfApprox_0.cxx
CAS3.0/drv/TopOpeBRepApprox/TopOpeBRepApprox_BSpGradient_BFGSOfMyBSplGradientOfTheComputeLineOfApprox_0.cxx
CAS3.0/drv/TopOpeBRepApprox/TopOpeBRepApprox_ParLeastSquareOfMyGradientbisOfTheComputeLineOfApprox_0.cxx
CAS3.0/drv/TopOpeBRepApprox/TopOpeBRepApprox_ResConstraintOfMyGradientbisOfTheComputeLineOfApprox_0.cxx
CAS3.0/drv/TopOpeBRepApprox/TopOpeBRepApprox_ParFunctionOfMyGradientbisOfTheComputeLineOfApprox_0.cxx
CAS3.0/drv/TopOpeBRepApprox/TopOpeBRepApprox_Gradient_BFGSOfMyGradientbisOfTheComputeLineOfApprox_0.cxx
CAS3.0/drv/TopOpeBRepApprox/TopOpeBRepApprox_ParLeastSquareOfMyGradientOfTheComputeLineBezierOfApprox_0.cxx
CAS3.0/drv/TopOpeBRepApprox/TopOpeBRepApprox_ResConstraintOfMyGradientOfTheComputeLineBezierOfApprox_0.cxx
CAS3.0/drv/TopOpeBRepApprox/TopOpeBRepApprox_ParFunctionOfMyGradientOfTheComputeLineBezierOfApprox_0.cxx
CAS3.0/drv/TopOpeBRepApprox/TopOpeBRepApprox_Gradient_BFGSOfMyGradientOfTheComputeLineBezierOfApprox_0.cxx
CAS3.0/drv/TopOpeBRepBuild/TopOpeBRepBuild_DataMapIteratorOfDataMapOfShapeListOfShapeListOfShape_0.cxx