Sometimes Being a Nerd is NOT_FUN_(aka.the_suck())
So I've been going 'round and 'round (including sending a DVD-R via UPS RED which - I'm told - was corrupted upon arrival) to get a binary database save file to the company that handles the database maintenance at one of my clients so that they can perform an upgrade to the system.
I finally bit the bullet... and did everything I could think of to make sure that the file got there intact:
* I ran a full verify (a sort of fake DB re-load and data check) of last night's database backup file save: AOK
* I ran an md5sum of same: 330413342523fc3a6f4462647e849a98
* I moved it to the Linux file server on the local network... md5sum: 330413342523fc3a6f4462647e849a98 (no loss of data)
* I gzipped it ... md5sum: e4e706a416e6f852074c007c865ea207
* I gunzipped it ... md5sum: 330413342523fc3a6f4462647e849a98 (no loss of data)
* I gzipped it again ... md5sum: e4e706a416e6f852074c007c865ea207 (same as before; we're OK so far)
* I uploaded it (gzipped) to the company (can't run an md5sum on their server...)
* I downloaded it to my home computer: (gzipped) md5sum: e4e706a416e6f852074c007c865ea207
* I gunzipped it at home ... md5sum: 330413342523fc3a6f4462647e849a98 (no loss of data)
* I sent the gzipped file back to the client server, gunzipped it, and RAN ANOTHER VERIFY on the database server
(I kid you not). It survived all that network time and now I know, given that it survived the entire round trip intact with nary a bitshift (provided there are no leaky microwaves or solar flares at their location), that file on their server is golden. It outta be... I'm going crosseyed.