GNOME Bugzilla – Bug 119245
unable to display FTP virtual directories on MS IIS server
Last modified: 2006-07-13 15:51:22 UTC
This bug originates from the redhat bugzilla: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=86027 ----- Description of problem: MS IIS5 you can define virtual directories, which don't show in the listing of their parent directory. When I try to access such directories with nautilus, I get and error message saying directory does not exist. In a network sniffer I see that nautilus gets a listing of the parent directory. Version-Release number of selected component (if applicable): nautilus-2.2.1-4 How reproducible: Always Steps to Reproduce: 1. Type a URL that points to a virtual dir on IIS5 FTP server in nautilus 2. 3. Actual Results: Error message telling that directory does not exist Expected Results: Display directory ----- I believe this is a problem with the gnome-vfs ftp method, but i haven't really verified that. If its really a nautilus problem we need to change the product.
Can anyone provide an URL to a ftp server that behaves this way?
this could be a nautilus problem, because I can read virtual directories via gnomevfs-ls
Thanks for your bug report. IIS servers aren't very widespread among OSS developers. So if nobody provides an URI to such a server, we can't fix this bug.
I've temporarily hosted a server to demonstrate this phenomenon here: ftp://68.35.20.125/ I've set up two tests. The first is a test to see if any old user can access an IIS virtual directory. I've made a virtual directory named 'virtdir' in the root ftp directory. It is invisible, and it's supposed to be, but if you manually type it in, you should see a readme.txt explaining that you're browsing it successfully. Normally, the following address line should work: ftp://68.35.20.125/virtdir/ This works fine with Firefox, but not with Nautilus. The second test involves IIS's automatic forwarding of a user to a virtual directory. From what I can tell, if you create a virtual directory with the same name as a FTP user's name, the user should be automatically forwarded to that virtual directory. I've created a user named 'ftpuser' with password 'password'. Normally, the following address line should work: ftp://ftpuser:password@68.35.20.125/ Once again, I've set up a new readme.txt file that congratulates successful FTP clients on being able to read it. This works with Firefox, but not with Nautilus. Note: I've set up the virtual directory named 'ftpuser' to be only accessible by ftpuser. Another note: User 'ftpuser' should not have to manually enter the virtual directory named 'ftpuser'--it should happen automagically. Ideally, this gets addressed quickly so that I can take the server down. But if it doesn't, my IP will probably change, or I'll take it down on my own. Email me and hopefully I'd be able to get it back up again. Also, because I'm hosting this on bloody XP, only 10 connections are allowed at once, so please do not hog the server if you don't need to.
"From what I can tell, if you create a virtual directory with the same name as a FTP user's name, the user should be automatically forwarded to that virtual directory." BTW, here is a link on the methodology that IIS uses to do this and the steps that I followed to set this up: http://support.microsoft.com/kb/239120/en-us
I am able to read readme.txt from both URIs mentioned in comment 4 with Nautilus 2.15 :). Maybe you should upgrade your Nautilus/GnomeVFS version, at least to a recent 2.14 version?
Thanks for your response. I was using 2.14 from Ubuntu 6.06, and now I've upgraded to the 2.15.3 (latest CVS HEAD) version of Nautilus, and I've also updated the latest gnome-vfs from CVS HEAD as well, but the issue still persists. I may have been ambiguous with the expected results of the test. ftp://68.35.20.125/virtdir/readme.txt should read: "Yes! Your client can access virtual directories!" and ftp://ftpuser:password@68.35.20.125/readme.txt should read: "Your user has been successfully forwarded to a virtual directory!" This, of course, works as expected in Firefox, but doesn't seem to be working for me in Nautilus. If you can confirm that those readme.txt's read like the above, then I'll be content to figure out what else might need upgrading. :-/ Thanks.
Hrm from what I can see the first test passes as expected, while the second text has the problem that we decompose the passed-in URI and CWD into the path of the URI, i.e. we always do a "CWD /" before reading "readme.txt" (open your command line FTP client, enter "cd /" and "get readme.txt" and you'll get the wrong file). I'll reopen the bug report because I'm not sure how to resolve this issue and I can't find another bug report ATM. As far as I know, there is a proposed RFC for SFTP which distinguishes between a "relative root" and an explicitly set "absolute root". The latter reflects the current GnomeVFS semantics.
The relative root issue doesn't seem too bad in itself, since if a user knows what his relative root directory is supposed to be (since in IIS's case, this directory is invisible), he could just descend into it manually, or use Nautilus' File -> Connect to Server dialogue and specify it as the default directory in the "Folder:" field. However, the above workaround doesn't seem to work. I played around more with this test: ftp://68.35.20.125/virtdir/readme.txt and found that I *could* open it just fine *if* I open the file directly in gedit. But, say that I wanted to just browse: ftp://68.35.20.125/virtdir/ in Nautilus and then copy that readme.txt to my hard disk before opening it. Then Nautilus returns the 'Couldn't find "ftp://68.35.20.125/virtdir/".' error trying to browse that directory. So I don't think that Nautilus can list the files in a virtual directory. As noted in comment 1, I suspect that this is because the virtual directory is invisible, and Nautilus checks to see if it's there before trying to descend into it. (Unless this works fine for you, Christian.) Same for our hypothetical user ftpuser. If he types in: ftp://ftpuser@68.35.20.125/ and logs in, Nautilus still returns the "Couldn't find" error when ftpuser tries to connect to ftp://ftpuser@68.35.20.125/ftpuser/, which I think should work as a workaround, but doesn't.
"Comment 1" should be "comment 0" in the above.
> As noted in comment 1, I suspect that this is because the virtual directory is > invisible, and Nautilus checks to see if it's there before trying to descend > into it. Exactly, this seems to be the reason. Let's see whether we can do anything about it, but I'm not too optimistic.
Created attachment 68775 [details] [review] Proposed patch The attached patch allows me to open the specified directory with Nautilus. It is yet another ugly hack and shows how crappy FTP is, especially when servers don't stick to common (but underspecified) conventions :(.
Uhh ugly hack :) --- snipp --- + basename = g_path_get_basename (unescaped); --- snapp --- We are leaking this string in the else case, aren't we? More a cosmetic thing: --- snipp --- + if (result != GNOME_VFS_OK) { + result = GNOME_VFS_ERROR_NOT_FOUND; + } --- snapp --- Can't we make that "if (...)" be just an else of the previous if "(result == GNOME_VFS_OK)"? Like: if (result == GNOME_VFS_OK) { [Fill in file info] } else { result = NOME_VFS_ERROR_NOT_FOUND; } Otherwise it looks good, despite the fact that its a hack :)
> We are leaking (a) string in the else case, aren't we? Uhm it's NULL, right? > Can't we make that "if (...)" be just an else of the previous if "(result == GNOME_VFS_OK)"? Yes, good catch.
Created attachment 68863 [details] [review] Proposed patch #2
Ahh yeah, I didn't look at the if too close. Go ahead and commit that one!
Done :).