Transferring big files with EatLime, SendThisFile, and FTP

Shortly after writing about SendThisFile, I had to transfer some large files to a client. It's one thing to read about a product and kick the tires, but quite another to battle-test it. Here was a battle.

Since transferring large files can take hours, you need to be concerned with your computer going to sleep midstream. Many computers go into assorted suspended states when they haven't been used in a while. For example, the Power Options in the Windows XP Control Panel lets you set time limits after which the hard disk stops spinning, the entire computer goes into standby, or even turns itself off (hibernate). In the tests described below, I disabled all these "sleeping" options.

Although SendThisFile has no limit on the size of a file being sent/transferred, I started with the smallest file, which was 178MB. During the transfer, the status is shown visually with a dashed yellow bar that turns red from left to right. You also see the percent completed and the number of bytes transferred so far (megabytes would be much more useful). They show the elapsed time, but there is no estimate of the time remaining and no display of the transfer rate.

As previously described, the catch, if you will, with SendThisFile is that free uploads get slower and slower the more data you upload. This is visually indicated with a horizontal line that starts out all blue (for fast) and slowly migrates to yellow (for slow). In the screenshot, above the dashed line on the bottom is all blue because the file was small.

It took me 5 hours and 4 minutes to upload the 178MB on a cable connection where the upload speed is typically measured at 400 to 500Kbps. Since the other files I needed to transfer were 650MB, I decided to look elsewhere.

One thing is unresolved though. SendThisFile claims it is the only service that notifies the sender when the e-mail notification to the recipient can't be delivered. I tested this three times, however, and was never notified that the recipient e-mail address didn't exist.

FTP

There are many online services to transfer large files, files that e-mail can't handle. But 650MB apparently qualifies as really large, so the free options I found to transfer this big a file were few. Among the services whose limit was too small were YouSendIt, 4shared, MediaFire, and MailBigFile which each have a 100MB limit on single files. At GigaSize, the limit is 300MB, and at ShareBig, it is 350MB. Couriervault has no free service at all.

To nerds like us, the classic way to send big files is FTP (File Transfer Protocol). FTP is an oldie but goodie in the TCP/IP world and one of its advantages is it can handle files of pretty much any size. I'm fairly sure that FTP itself has no limit on file size. If you encounter FTP limits, they may be due to the host file system, the particular FTP software being used, or perhaps bandwidth limits on either the sending or receiving end.

On November 21 I tried to send one of the 650MB files to an FTP account I have at 1and1.com. The first upload aborted halfway through, but a second attempt completed.

On November 25, I sent another of the 650MB files to an FTP account I have at Pair.com. It completed the first (and thus only) time in roughly 3.5 hours (I wasn't watching the time closely).

Although there are many FTP programs, in general they are not as easy to use as the newer online services. They are certainly more complicated.

EatLime

EatLime was recommended by someone who commented on my initial writeup of SendThisFile. If you register, it will transfer files up to 1GB, so I gave it a try. It's not clear from the Web site what the file size limit is if you don't register.

Registration was unusually easy; just provide an e-mail address. There wasn't the usual confirmation e-mail message with a special code or link to complete the registration.

The service couldn't be any easier to use without registering. All you have to do is select a file and the upload starts. You don't even need to provide an e-mail address for the recipient of your file. Instead, as soon as the file upload starts, you are shown a link like

http://www.eatlime.com/download.lc?sid=xxxxxxxxxxxxxxx

Simply click on this link to download the file. You can provide this link to someone even before the upload has completed.

Small files are confusing though. I uploaded a file of 71K and after the upload completed, the file size was shown as 0MB, which looks like the upload failed. But, the upload ran fine; this is poor programming dealing with rounding error. When I went to download the file, the size was reported as 0.1MB.

While a file is uploading you can watch the percent complete and the upload speed, but there is no display of the elapsed time and no estimate of the completion time.

I first tried to upload a 650MB file on November 24. It got to 39 percent complete and failed with a "read/write error." A few days later it occurred to me to try and use the provided download link, just for the heck of it. When I did, EatLime reported that the full 650MB file existed on its servers.

Not only did the file upload fail but it screwed up my router. The two computers on my LAN couldn't get to any Web sites, with either Internet Explorer or Firefox. They could each do e-mail and other online services, but HTTP seemed to be broken. Rebooting the router fixed things.

I tried it again. This time, the upload got to 23 percent before the "upload failed with a read/write error" again. The router was not affected this time.

I waited about an hour and tried again. This time it died at 36 percent complete and, again, I had to restart my router because I couldn't get to any Web sites afterwards.

The next day, I tried yet again with the same file. This time it got all the way to 61 percent complete before failing with the same read/write error.

Next time, my experience sending a 650MB file using DropSend and TransferBigFiles.