Version 4.2.3 file partially corrupt on sftp transfer

Advertisement

Freitag
Freitag avatar
Joined:
Posts:
52

Version 4.2.3 file partially corrupt on sftp transfer

It has not happened before and it has not happened since. It was a one time event. So this was probably a local network issue. But this is "beta" so I am reporting for completeness.


A text file that I was transferring had that last few hundred bytes turned into random binary gibberish.


The remote server is AIX version 5.3

I am using a shortcut with the "Target" =

"C:\Program Files\WinSCP\WinSCP.exe" /ini="C:\MyStuff\Config Files (irreplaceable)\WinSCP\WinSCP-dev_env.ini" "sftp://MY_USER:MY_PASS@MY_SERVER/apps/control/"

to log in.

The .ini file just has the generic settings for a dev type environment.

Reply with quote

Advertisement

martin
Site Admin
martin avatar
Joined:
Posts:
27,253
Location:
Prague, Czechia

Re: Version 4.2.3 file partially corrupt on sftp transfer

Let me know if it ever happens again.
_________________
Martin Prikryl

Reply with quote

Freitag
Freitag avatar
Joined:
Posts:
52

It just happen again.

The steps this time were a little different.

Remote server is Solaris

uname -a says:
SunOS SERVER_NAME 5.10 Generic_127111-09 sun4u sparc SUNW,Sun-Fire-V245

I had two files in remote sub-directory and I copied them to main directory using local directory (because direct copy gives that memory access error message)

Only one file (the first one) was damaged in transfer. Using od -X I see that part of the file is replaced with null and some bytes are truncated.

Here is the section of the log file that covers the transfer that trashed the files.

<download>
<filename value="/home/USER_NAME/o27/cb_and_cpb.ORIG.sort_of/cb.ksh" />
<destination value="C:\DOCUME~1\WIN_USER_NAME\LOCALS~1\Temp\scp36459\home\USER_NAME\o27\cb_and_cpb.ORIG.sort_of\cb.ksh" />
<result success="true" />
</download>
<download>
<filename value="/home/USER_NAME/o27/cb_and_cpb.ORIG.sort_of/cpb.ksh" />
<destination value="C:\DOCUME~1\WIN_USER_NAME\LOCALS~1\Temp\scp36459\home\USER_NAME\o27\cb_and_cpb.ORIG.sort_of\cpb.ksh" />
<result success="true" />
</download>
<upload>
<filename value="C:\DOCUME~1\WIN_USER_NAME\LOCALS~1\Temp\scp36459\home\USER_NAME\o27\cb_and_cpb.ORIG.sort_of\cb.ksh" />
<destination value="/home/USER_NAME/o27/cb.ksh" />
<result success="true" />
</upload>
<touch>
<filename value="/home/USER_NAME/o27/cb.ksh" />
<modification value="2009-09-03T20:29:56.000Z" />
<result success="true" />
</touch>
<upload>
<filename value="C:\DOCUME~1\WIN_USER_NAME\LOCALS~1\Temp\scp36459\home\USER_NAME\o27\cb_and_cpb.ORIG.sort_of\cpb.ksh" />
<destination value="/home/USER_NAME/o27/cpb.ksh" />
<result success="true" />
</upload>
<touch>
<filename value="/home/USER_NAME/o27/cpb.ksh" />
<modification value="2009-09-03T20:31:08.000Z" />
<result success="true" />
</touch>

Reply with quote

martin
Site Admin
martin avatar
Joined:
Posts:
27,253
Location:
Prague, Czechia

Thanks. So does the corruption happen on upload?

Are you able to reproduce it? Would it be worthwhile to send you a debug version?
_________________
Martin Prikryl

Reply with quote

Freitag
Freitag avatar
Joined:
Posts:
52

martin wrote:

Thanks. So does the corruption happen on upload?

Are you able to reproduce it? Would it be worthwhile to send you a debug version?

It happens on upload.

I'm unable to force it to occur (it is rare)

I'd use a debug version if you sent it.

Reply with quote

martin
Site Admin
martin avatar
Joined:
Posts:
27,253
Location:
Prague, Czechia

Problem is that have no idea what may cause this, so it would involve improving the debug version iteratively. And as you are not able to reproduce the problem easily it would take ages.
_________________
Martin Prikryl

Reply with quote

Freitag
Freitag avatar
Joined:
Posts:
52

martin wrote:

Problem is that have no idea what may cause this, so it would involve improving the debug version iteratively. And as you are not able to reproduce the problem easily it would take ages.

I did notice that the byte count of the file changed on this last time.

Perhaps if some detailed logging was stored in memory all the time and after each file transfer, if the byte count is right, wipe the logging, but if the byte count changes, then write the log file?

Oh, also, this is not strict file transfer, this is double click on file to open in edit mode locally - then use File/Save and have the remote file update.

Reply with quote

Advertisement

You can post new topics in this forum