Forum Moderators: phranque
Local:_________________________Remote Site (server):
butter.jpg (67890 bytes) ------> butter.jpg (0 byte)
egg.gif (156789 bytes) --------> egg.gif (0 byte)
I do not know what these aborted transfers mean and the problem behind them, however. This is a problem I can't have for too long, since I need to update my site.
I tried other FTP programs, such as WS_FTP LE. It's almost the same thing but only a portion of a file is transferred to a server. It's like this:
Local:_________________________Remote Site (server):
butter.jpg (67890 bytes)-------> butter.jpg (2560 bytes)
egg.gif (156789 bytes) --------> egg.gif (2560 bytes)
Is this "2560 bytes" a limit or what? Did I miss something, like change a setting? Any help is appreciated.
*BTW, I'm still using a dial-up internet connection. Does it have something to do with connection too? I previously worked with CuteFTP on a computer with cable internet access, and the transfers/uploads were quite successful.
What about the "0 byte" thing? I think that's where th problem is. And what do you mean by "timing out at your end"?
The Status window(CuteFTP) gives messages like this whenever I try to upload an image file:
--------
status:> sending butter.jpg
.
.
.
status:> connecting data socket
150 starting Binary Transfer
426 transfer aborted. 0 bytes transferred
error:> can't send data. Terminating send process
error:> File error
status:> Failed to send C:\pictures\butter.jpg
--------
I'm planning to concentrate more on freeware FTP programs like WS_FTP LE but I keep having a similar problem, only that a portion of a file is transferred. So if I view the image on the webpage, it's not complete.
Regarding WS_FTP LE:
I tried this one too. I think I will concentrate more on this one because its freeware. But here's what I noticed: at a transmission size (network buffer size) of 80 (minimum), the size transferred is always 2880 bytes no matter how large the file is. If I increase that to 512 bytes, the size transferred is 2560 bytes. Now if I increase that again to the maximum 4096 bytes, the size tranferred is 0 bytes. I'm confused. Does this have something to do with my internet connection speed? I'm on a 56 K dial-up connection but only with a crappy 48 kbps connection speed. Is this slow enough?
The Help file has this to say about the Network Buffer Transmission size (32-bit version):
Send bytes (16-bit version)
"This option controls how many bytes are written to the network in each send. The value can vary from 80 to 4096. The optimum value to place here depends on your TCP/IP stack. If you have a direct connection, 4096 is best. If you have a SLIP/PPP connection, you probably want to set it to MTU size."
Sorry for having so many questions regarding this problem. I'm relatively new to FTP and I need all the help I can get.
I did this once without realising and kept trying to upload files without realising that I have used all my space.
The files registered their presence on the server but with no file size.
Could be totally rubbish, but worth checking I guess.
David
How come the file sizes on the remote site and on the local site do not match? Usually if i upload smaller files, the files register the same size. If I do bigger ones, the files register on the server way bigger. I noticed that it usually happens when the program tries to reconnect to the host and then resumes the transfer. And m sure I keep seeing a message "Site cannot resume broken transfers" in the status window. What does that mean?
You may be using a compressed drive and the server most likely is not. Also, the server's HD has probably been set up to use a different byte container than your computer. Think of a garage and a car. The garage is often larger than the car to allow for different sized cars. In the case of the HD, the space alloted to store data (the car) is the garage (the container). If the data exceeds that container, the server tacks on another 'garage'. It can't just allot the exact amount of space required by the data - too slow for data reads, writes, and deletes. So it is often the case that the server has designated more space than is actually required to hold the data.
As for the message "Site cannot resume broken transfers" - some FTP servers use a mechanism to track file transfers. If the transfer is broken for some reason, and you restart it, the FTP server will pick up where it left off. In your case, however, it appears they're telling you they don't do this.
The symptoms you describe indicate that the problem is not cuteFTP; its just that cuteFTP detects very early in the piece that there is likely to be a problem in the transfer. To be honest, I have found CuteFTP quite good... it has worked for me in situations where other ftp packages haven't.
The symptoms you describe where WS_FTP sends less if the buffer size is increased is understandable. Just imagine that a problem occurs when WS_FTP gets to a certain byte in the file, and you will understand why.
From the syptoms you describe, it looks to me like a problem with your local files butter.jpg and egg.gif. Perhaps a bit of disk corruption around 2k into the files. That's just a bit of a gut feel, not a scientific analysis; but it might be worth trying to send a different file to see.
Shawn
The other times, they did not tell me why, but simply did something that fixed the problem. Hope this helps.
Lorax - I changed server and now it says it supports resumes of broken transfers. But whenever I upload files about 30 kb in size or higher, the process would go on for a few minutes then it would stop, saying (in the status window)"Unable to open file."
Dave - How do I change the TCP/IP stack settings? Where will I go?
Guillermo - Thanks for letting me know that I am not alone on this one. I'll try another time and check if they fixed the problem.
Shawn - Sometimes I think the problem is me, not CuteFTP. I'm too newbie on this one, although I can learn the technical parts easily enough.
