FTP through explorer strips content of some files

I am having a weird problem when I try to ftp files through explorer - certain files are completely stripped of their content. I've attached some sample files to this message. The files that start with "doesnt_work" will get stripped when copied over ftp. The files that start with "works" will not get stripped. The only difference between the works and doesn’t_work is that I have removed some of the content for the works version.

Some facts:

• All the files are plain text.
• I've verified that this happens on multiple ftp servers.
• It happens regardless of the file extension.
• I've turned off antivirus and netnanny software and it still happens.
• If I use another ftp client such as CoreFTP lite, or ftp.exe from the command line, it doesn't happen- all files transfer properly
• This also happens with explorer-ftp transfers on windows XP.

Anybody know what is happening?

Very interesting.

If I understand correctly, the "doesnt_work" versions of these files end up completely devoid of content at the other end? Are they 0 byte files?

How did you arrive at the conclusion that removing some of the initial content allowed the file to go through intact? Trial and error? Do you now know exactly what you have to first remove from each (text) file in order for it to be sent across?

You have multiple machines doing this - one Vista and one XP? Are they both behind the same firewall? What sort of firewall is it? A corporate setup? Are there any other clients behind the same firewall which are NOT behaving this way during Iexplore.exe FTP transfers?

Does the same thing happen if you boot to [safe mode + net] and try from there? What about if you temporarily deactivate all IE add-ons?

If the (external) firewall is not what's causing this symptom on multiple machines, then perhaps they all have the same faulty or misconfigured software component. Unlike those other apps you listed (which work), IE FTP uses the WinInet API and not straight sockets, so it may be affected by some sort of vestigal anti-malware filter while those other apps work successfully. It could also be an add-on running in the Iexplore.exe process.

A bit more info and I'm confident it'll be possible to diagnose the cause.

Sulfuric,

Evarmint displays files that don't work as being 3.3 and 5.3 kb. It does contain information from Micosoft (Word?).

What I find interesting is some files d/l fine, others do not. And he can successfully ftp files via the command line ftp. At first I thought it was ascii vs. binary problem. But I'm not sure that's the case. Especially if he opens an ftp windows and does not specify ascii or bin and it works in that scenario.

What gets me is content being stripped.

Evarmint - if you zipped these files, would they download via explorer without incident?

lemur said:

Sulfuric,

Evarmint displays files that don't work as being 3.3 and 5.3 kb. It does contain information from Micosoft (Word?).

Click to expand...

Personally, I'm not entirely clear on what happens to the non-working files, so I was hoping the OP could provide a bit more detail.

lemur said:

What I find interesting is some files d/l fine, others do not. And he can successfully ftp files via the command line ftp. At first I thought it was ascii vs. binary problem. But I'm not sure that's the case. Especially if he opens an ftp windows and does not specify ascii or bin and it works in that scenario.

What gets me is content being stripped.

Click to expand...

Yes, I agree, the text/binary distinction should be considered, but these files all seem to be text-only, plus trying to transfer binary files in text mode leads to corruption, not the "stripping" of all content from the file. (Those characters which are "high" ASCII and require a leading 8th bit end up getting mangled).

I hope the OP will provide answers to some of our questions because I'd be curious to understand the cause.

If I understand correctly, the "doesnt_work" versions of these files end up completely devoid of content at the other end? Are they 0 byte files?

Click to expand...

That's mostly correct. Right after they transfer, they will show the correct length, but after I refresh, they show zero length. I have verified that they are truly empty.

How did you arrive at the conclusion that removing some of the initial content allowed the file to go through intact? Trial and error? Do you now know exactly what you have to first remove from each (text) file in order for it to be sent across?

Click to expand...

I had a suspicion that it might be due to the content, so I randomly took out bits of the xml to see what I could learn. I learned there is no linear pattern to it. Only certain combinations of content removal cause the problem to go away, but nothing that looked obvious or predictive.

You have multiple machines doing this - one Vista and one XP? Are they both behind the same [COLOR=#3676a2! important][COLOR=#3676a2! important]firewall[/COLOR][/COLOR]? What sort of firewall is it? A corporate setup? Are there any other clients behind the same firewall which are NOT behaving this way during Iexplore.exe FTP transfers?

Click to expand...

Yes, both machines are behind the same Firewall (my FIOS router at home). I have have a third client (Win7) up soon to test. In the mean time, I tried this out at work on a Vista machine and it does not appear to be happening there.

Does the same thing happen if you boot to [safe mode + net] and try from there? What about if you temporarily deactivate all IE add-ons?

Click to expand...

I haven't tried these yet.

If the (external) firewall is not what's causing this symptom on multiple machines, then perhaps they all have the same faulty or misconfigured software component. Unlike those other apps you listed (which work), IE FTP uses the WinInet [COLOR=#3676a2! important][COLOR=#3676a2! important]API[/COLOR][/COLOR] and not straight sockets, so it may be affected by some sort of vestigal anti-malware filter while those other apps work successfully. It could also be an add-on running in the Iexplore.exe process.

Click to expand...

Given that this is happening on two different machines at home, and not on another network, I think this is pointing to the FIOS router. Any theories as to why this would not work under explorer, but would work with FTP clients? I can only assume that they are implementing the FTP protocol differently at some level.

evarmint said:

Given that this is happening on two different machines at home, and not on another network, I think this is pointing to the FIOS router. Any theories as to why this would not work under explorer, but would work with FTP clients? I can only assume that they are implementing the FTP protocol differently at some level.

Click to expand...

The firewall/router commonality is obviously significant, but I don't think you can be reasonably certain the firewall is the cause - yet. As you pointed out, the fact that it only affects FTP when done through IE does not readily lend itself to the "firewall did it" theory.

Having said that, if IE is configured to do FTP through a CERN proxy, then its FTP behaviour will be different to the other dedicated FTP clients. You might want to check the proxy settings in IE and disable FTP-through-proxy if that's currently configured.

The other possibility which springs to mind is a difference in the default active/passive FTP configuration which exposes a fault in the FIOS firewall. For example, ftp.exe does active FTP by default, as would that other dedicated FTP client you mentioned. If ftp.exe also breaks the same way when you go over to passive mode (QUOTE PASV), then that would be highly significant.

It'll be very interesting to see how the (clean) Win7 box behaves behind the same firewall. In the meantime, I'd suggest you try booting Vista and/or XP to [safe mode + net] to test from there. It's not going to take long to try that.