OT: PSA re: XFTP5

[Don Y]

Just an FYI for folks who might be using this "tool"...

Frantic call from a client complaining "all his files were corrupted".

After a bit of research, the problem apparently is the result of his
using NetSarang's XFTP product (v5 build 1249 -- though I believe the
bug resides in many releases!) to transfer large numbers of files
between his Linux file server and Windows. Once transferred, the
files are very obviously NOT identical copies of the originals (file
sizes differ, as do content).

I verified this behavior wrt a BSD server as well.

ISTR researching this some time ago and the NetSarang concensus was
"<shrug> We can't duplicate the problem...". IIRC, I concluded
it was incorrect newline handling -- despite configuring the client
to treat all transfers in Image mode.

My solution: use another tool -- one that actually DOES preserve
file integrity! (or fight with NetSarang until they *can* reproduce it)

<shrug> YMMV.

*out*

 

[Clifford Heath]

On 22/1/20 3:26 pm, Don Y wrote:

Just an FYI for folks who might be using this "tool"...

Frantic call from a client complaining "all his files were corrupted".

After a bit of research, the problem apparently is the result of his
using NetSarang's XFTP product (v5 build 1249 -- though I believe the
bug resides in many releases!) to transfer large numbers of files
between his Linux file server and Windows.  Once transferred, the
files are very obviously NOT identical copies of the originals (file
sizes differ, as do content).

I verified this behavior wrt a BSD server as well.

ISTR researching this some time ago and the NetSarang concensus was
"<shrug>  We can't duplicate the problem...".   IIRC, I concluded
it was incorrect newline handling -- despite configuring the client
to treat all transfers in Image mode.

My solution:  use another tool -- one that actually DOES preserve
file integrity!  (or fight with NetSarang until they *can* reproduce it)

shrug>  YMMV.

*out*

It's possibly using CRNL translation mode, not binary.
Is there a "use binary" flag somewhere?

CH

 

[Don Y]

On 1/22/2020 12:12 AM, Clifford Heath wrote:

On 22/1/20 3:26 pm, Don Y wrote:

ISTR researching this some time ago and the NetSarang concensus was
"<shrug> We can't duplicate the problem...". IIRC, I concluded
it was incorrect newline handling -- despite configuring the client
to treat all transfers in Image mode.

It's possibly using CRNL translation mode, not binary.
Is there a "use binary" flag somewhere?

"despite configuring the client to treat all transfers in Image mode."
----------------------------------------------------------^^^^^

In addition:
- Limit client to a single transfer per connection (complexity reduction).
- Ensure file names are not *suggestive* of ASCII content.
- Ensure *content* can't realistically be deduced to be ASCII (they aren't!)
- PUT and GET files

Record file sizes of originals vs. "as transferred"
Compute hashes of originals vs. "as transferred"
Check logs in client.
Check logs on server.

Client (tool) is *clearly* not adhering to expressed wish of transferring in
Image mode.

Provide "evidence" to (my) client. Let him decide if he wants to
pester vendor for a RE-bugged version -- or, just "move on" (as I'd
suggested, previously)

[Dig out old email where I'd originally informed him of this potential
problem to further pressure him not to bother me with *his* mistakes; my
support agreement only extends to issues that are related to *my* work,
not *his* choice of tools!]

If the tool doesn't satisfy it's PRIMARY PURPOSE (accurate file
transfers), then what good is it? Like having a cell phone with
persistent connection problems... "yeah, but it KEEPS GREAT TIME!"

:-/