Folks, I'm having issues checking for and downloading updates from a new FTP server. This process worked with the old server (Windows) but not with the new one (Linux). Here are the particulars:
I can build and upload the updates just fine from a Windows build machine.The upload user is different from the download user, but they are both in the same group. That group has read permissions to the update files on the server.I am performing the update manually on my client machine (Windows) using wyUpdate.exe and client.wyc.When I run wyUpdate in the folder containing client.wyc, I get the update window telling me that wyUpdate is checking for updates.The update window then tells me it encountered an error (Unable to check for updates, the server file failed to load), and when I press the "Details" button, I get the following:Error trying to save file: Error downloading "ftp://user:password@myftp.myhost.com/MyUpdates/Client/wyserver.wys": The remote server returned an error: (550) File unavailable (e.g., file not found, no access).
It seems that my client.wyc file is OK, since wyUpdate knows where to go for the updates. I know that the wyserver.wys file is on the FTP site and can be downloaded to the client machine. I did so three different ways:1. FileZilla, using the host and credentials above2. Command-line ftp, using the host and credentials above3. Internet Explorer, using the URI above.
I'm having my site admin tweak the file permissions (currently 644) to see if that makes a difference, but beyond that, I'm stumped as to why wyUpdate has trouble with the download while the other applications don't.
Have you folks had any issues with non-Windows FTP sites? Also, is there some other possibility that I've overlooked?
Thanks...
wyUpdate should download fine from FTP servers no matter what platform the server is running on.
Have you tried copying & pasting the site exactly as wyUpdate shows in the error and pasting that into a browser? The reason I ask is that linux is case-sensistive (i.e. "/Updates/" is different than "/updates/").
Yes, I used the exact string from the error message in IE and the file came down just fine.
I also tried changing the client to use the credentials that the upload used and that failed.
I also tried changing the permissions to the wyserver.wys file on the server to 777 and it still didn't work.
Have I missed something? I doubt that the client.wyc file is bad since its URI is showing up in the error message. I suspect I'll have to put a sniffer on the line and see if I can get any more detail as to what exactly is failing.
Send me your client.wyc file to support@wyday.com. I'll test it out and see what's wrong.
Actually, I've dug into this a little more by downloading and stepping through the wyUpdate source -- thanks for making it available!! The problem is occurring when the downloader is asking the server for the file size (WebRequestMethods.Ftp.GetFileSize). This request throws the WebException whose Message is shown in the UI's error text.
In the Response property of the WebException, the StatusDescription property states that "550 SIZE not allowed in ASCII mode". This is occurring despite the fact that Binary is set to true by default in the FtpWebRequest that's getting sent. Apparently this is a known issue (http://social.msdn.microsoft.com/forums/en-US/netfxnetcom/thread/0c38814e-d8e3-49f3-8818-b5306cc100ce/), has been for a long time, and is still an issue (http://aautar.digital-radiation.com/blog/?p=646) despite the fact that Microsoft said in 2007 that it will be fixed in a future release.
I can't say exactly why the three other clients I've tried aren't failing, but perhaps they're not asking for the file size before downloading the file. I'm going to try a few workarounds locally to see if I can somehow get going with the download.
We found a solution. Our site admin configured the server to set the default transfer mode to binary, and now things are working correctly.
Presumably a Windows server is already set up this way.
In any case, this will be useful information for anyone else who's using a non-Windows update host.
Thanks for listening!
I'll see if we can fix wyUpdate to skip the FTP size command if it fails. But you're right to fix the transfer mode -- if the ASCII transfer had succeeded (or, completed, rather) then it's unlikely the file would be valid (because ASCII mode modifies the data while it's being transferred).
At any rate, thanks for tracking down the problem.
jfgraitecI have the same problem. I got the version 2.6.14 of wyUpdate. Is it fixed in the latest version of wyUpdate?Sorry to revive a very old thread!
Fix your FTP server to transfer the file as binary.
