[CentOS] Gulliver

Tue Oct 31 18:47:10 UTC 2017
Gordon Messmer <gordon.messmer at gmail.com>

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.