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@centos.org
https://lists.centos.org/mailman/listinfo/centos
