On 10/30/2017 10:07 AM, Chris Olson wrote:
All files are loaded or moved from one machine to another with sftp. The intern noticed right a way that the documents will transfer perfectly from our PPC and SPARC machines to our Intel/CentOS platforms. The raw data files, not so much. There is always an Endian (Thanks Gulliver) issue, which we assume is due to the bytes of data being formatted into 32 bit words somewhere in the Big Endian systems.
It's unlikely that copying the files is causing the problem you observe. As Peter suggested, you can use "md5sum" on the source and destination hosts to demonstrate that the files are not being modified in transmission.
However, endianness can be a problem if the applications you use naively save data to a file in their native byte order, and also read in native byte order. In situations like that, a big-endian system will save data that the same application will fail to read, when it is run on a little-endian system.
If this is an application that you've developed in-house, you should be using htonl() to convert your 32-bit values to network byte order and writing that value to the data file, and using ntohl() to convert 32-bit values that you read from data files to the native host byte order.
_______________________________________________ CentOS mailing list CentOS@xxxxxxxxxx https://lists.centos.org/mailman/listinfo/centos
