Tests fail under Windows #3
Comments
|
@WoolenWang, Thank you for opening this issue. It is my intent that ftpd work on Windows if at all practical. However, since I have only a Linux system to develop and test with, it is likely that I have accidentally used functions which do not work in Windows. But I don't know. Have you tried ftpd on Windows and found it did or did not work? If it did not work, specific bug reports (stack traces, etc.) would be very helpful, and patches from a developer with access to Windows would be most welcome. |
|
@wconrad i just ran the tests on a win 8 x86 machine with ruby 1.9.3p448 [i386-mingw32] (installed via windows ruby installer). apparently most of the problems stem from the lack of symlinks on windows filesystems. I'll have an eye on this. Here is the output : |
|
@m0x - I'm excited to finally see what goes wrong in Windows. Thanks! The good news about the symlink issue is that it's just the spec itself using symlinks -- it wants to make sure that a symlink is treated as the thing it links to (FTP servers don't expose symlinks--or, at least, ftpd doesn't expose symlinks). It might be as simple as recognizing that the test is running under Windows and not creating (or checking) the symlink under that condition. Did the cucumber tests (run with "rake test:features") show failures as well? |
|
@wconrad the cucumber features show a lot of failures... bad news is, the tests seem to freeze my computer, too! Could not get a decent output to show you because of this. I'm also trying to run the basic example in the readme ; the script runs well but as of now I did not manage to connect to the server using Filezilla or whatever. Could be my network settings (I'm a poor network admin, especially on windows), but even with a disabled firewall it does not seem to work (connection is refused). |
|
Managed to get the example working. For some reason, windows seems to allow With Filezilla, the initial handshake seems to go pretty well, but no commands seem to really work. As you know, I'm not really familiar with the FTP protocol, so maybe this will make more sense to you (barely translated filezilla output) : |
|
@m0x - OK, so getting windows working is going to involve some detective work. In any case, it is often a good strategy to fix the failing rspec tests first before worrying about the cucumber tests. The specs that are failing with the missing Socket::IPV6_V6ONLY error are not surprising, now that I look at the code. That constant exists to support #getsockopt under *nix. #getsockopt is a cross-platform bugaboo. It looks like the file system is failing under Windows. This: should not happen. Filezilla is trying to change the current directory to /. That directory should exist; it's the temporary directory created by the example out of which it serves files. There's also the potential, I suppose, that it's the example itself that is failing when it creates that temporary directory. Here's how to read that debug output from Filezilla. You are looking at a transcript of the control channel between the client and server. Each line with The client has connected; the server announces its version. The client sends the user name. The server tells the client that it needs to send a password The client sends a password. Authentication succeeds and the client is logged in. The client asks for the current directory; the server replies The client asks that data transfers be done in binary mode. FTP supports an ascii mode which translates line-endings, so that, for example, a Windows user downloading a file with Unix line endings ends up with "\r\n" on his end, even though the line endings are just "\n" on the server end. FTP is a strange protocol in that the server attempts to make a data connection back to the client in order to transfer files and directory listings. With most clients being on a private network behind a firewall, that doesn't work too well. Passive mode tells the FTP server that, instead of the server making a data connection to the client, the client will be making a data connection to the server. The 56096 tells the client what port to connect to. The client wants a list of files; the server sends it. The list is not displayed in this transcript (the list goes over the data channel, not the control channel). Change directory to /. This is where things go weird. The client attempts to create the directory, no doubt in response to the failure of "CWD /". That doesn't work, either. The client attempts to change to / again. Still no good. SIZE is an optional extension that FTPD does not support. It is supposed to report the number of octets that will be transferred when that file is downloaded. There is a relatively small set of core commands that must be supported by an RFC compliant FTP server. Clients are supposed to adapt gracefully to missing commands; the client does in this case. MDTM is another optional extension.. I don't know what it does. If I recall, passive mode should be entered for each file transfer/directory listing. The client is going to transfer a file, so it enters passive mode again. And, finally, the client attempts to store the file. This fails, probably for the same unknown reason that the CWD/MKD commands have failed. |
|
By the way: There's a fork of ftpd by @david-s-anderson that has something to do with Windows file systems. There's no pull request associated with it, and I've had no communication with the author, so I don't know anything about it: |
|
The change does allow files to be downloaded; however, I also had an issue with EPSV commands because they are not implemented. A workaround is to get the client to only attempt to connect over IPv4. |
|
@david-s-anderson - Thank you. Since you created your fork, I added IPV6 support to ftpd. However, it turns out that there's a problem with the IPV6 support under Windows, so that would need to be fixed, too. Do you recall what File.expand_path was doing wrong under Windows that your patch fixes? I'd like to understand it a little better. I have to think that the way ftpd calls expand_path is somehow depending upon some undefined behavior--after all, expand_path is supposed to work just as well in Windows as it does under Linux. |
|
@m0x and other interested parties, I've created a new feature branch, windows, for attempting to get ftpd to work with Windows. It contains hoped-for fixes to all known issues, namely:
Your testing and feedback are greatly appreciated! |
|
I've added instructions to the README about how to use the experimental Windows branch. All you need is this line in your Gemfile: Feedback needed! If it works for you, or does not, please add a comment here. |
|
When I start the ftp service, I can enter username and password for authorization. But after this, the following warnings come out.
|
Not support Windows file system???
The text was updated successfully, but these errors were encountered: