on ubuntu launchpad they discussed this bug also. it got closed because nobody could provide a debug output on fail. their guess was an encoding issue.

Can anyone provide a "windows" (I guess you mean IIS?) ftp server to test against?

I found a similar issue, not only with windows ftp servers:
http://bugzilla.gnome.org/show_bug.cgi?id=560357

To test if this bug is a duplicate, please try in a shell:

  ftp <ip_of_your_server>
  User: <your_username>
  Password <your_password>
  ftp> pwd
  257 "XXXXX" is current directory.

... and confirm here, if "XXXXX" is not equal "/"
(Then this bug is most likely a duplicate)

Please test with

ftp.sitecbr.com.br
User: sitecbr
Pass: e-mail-me...

Yes, the current directory is /sitecbr under this ftp server...

I got to test the ftp site and found atleast two issues:

1. The root directory is not listable - same as bug #520399 and bug #551822 
2. Leaving the initial directory (which is not /) will leave you in a dead end with no return (and both "ls .gvfs/ftp*/" and "gvfs-ls ftp://..." did "CWD /" according to "gvfsd -r" debug output.)


Debug output from lftp:
---------------------------------------------------------------------

$ lftp
lftp :~> debug
lftp :~> open ftp://sitecbr@ftp.sitecbr.com.br
Password:
---- Resolving host address...
---- 1 address found: 200.98.196.3
lftp sitecbr@ftp.sitecbr.com.br:~> pwd
ftp://sitecbr@ftp.sitecbr.com.br
lftp sitecbr@ftp.sitecbr.com.br:~> ls
---- Connecting to ftp.sitecbr.com.br (200.98.196.3) port 21
<--- 220
---> FEAT
<--- 211-Extended features supported:
<---  LANG EN*
<---  UTF8
<---  AUTH TLS;TLS-C;SSL;TLS-P;
<---  PBSZ
<---  PROT C;P;
<---  CCC
<---  HOST
<---  SIZE
<---  MDTM
<--- 211 END
---> AUTH TLS
<--- 534 Local policy on server does not allow TLS secure connections.
---> LANG
<--- 200 Language is now English, UTF-8 encoding.
---> OPTS UTF8 ON
<--- 200 OPTS UTF8 command successful - UTF8 encoding now ON.
---> HOST ftp.sitecbr.com.br
<--- 504 Server cannot accept argument.
---> USER sitecbr
<--- 331 Password required for sitecbr.
---> PASS XXXX
<--- 230 User logged in.
---> PWD
<--- 257 "/sitecbr" is current directory.
---> PASV
<--- 227 Entering Passive Mode (200,98,196,3,195,89).
---- Connecting data socket to (200.98.196.3) port 50009
---- Data connection established
---> LIST
<--- 150 Opening ASCII mode data connection.
<--- 226 Transfer complete.
---- Got EOF on data connection
---- Closing data socket
drwxrwxrwx   1 owner    group               0 Jan 19 17:10 Dados
drwxrwxrwx   1 owner    group               0 Jan 21 17:56 Jefesson
drwxrwxrwx   1 owner    group               0 Jan 19 17:10 Logs
drwxrwxrwx   1 owner    group               0 Jan 21 19:13 Publico
drwxrwxrwx   1 owner    group               0 Jan 22  8:25 Web
lftp sitecbr@ftp.sitecbr.com.br:~> pwd
ftp://sitecbr@ftp.sitecbr.com.br/%2Fsitecbr
lftp sitecbr@ftp.sitecbr.com.br:~> cd /
---> CWD /
<--- 250 CWD command successful.
cd ok, cwd=/
lftp sitecbr@ftp.sitecbr.com.br:/> ls
---> PASV
<--- 227 Entering Passive Mode (200,98,196,3,195,84).
---- Connecting data socket to (200.98.196.3) port 50004
---- Data connection established
---> LIST
<--- 150 Opening ASCII mode data connection.
<--- 226 Transfer complete.
---- Got EOF on data connection
---- Closing data socket
lftp sitecbr@ftp.sitecbr.com.br:/> cd ~sitecbr
---> CWD ~sitecbr
<--- 550 The system cannot find the file specified.
cd: Access failed: 550 The system cannot find the file specified.  (~sitecbr)
**** control-socket: Connection reset by peer
---- Closing control socket
lftp sitecbr@ftp.sitecbr.com.br:/>




Debug output from gvfsd:
---------------------------------------------------------------------

$ /usr/lib/gvfs/gvfsd -r

Added new job source 0x11220c0 (GVfsBackendFtp)
Queued new job 0x1123030 (GVfsJobMount)
<-- 220
--> USER sitecbr
<-- 331 Password required for sitecbr.
--> PASS ***
<-- 230 User logged in.
--> TYPE I
<-- 200 Type set to I.
--> FEAT
<-- 211-Extended features supported:
<--  LANG EN*
<--  UTF8
<--  AUTH TLS;TLS-C;SSL;TLS-P;
<--  PBSZ
<--  PROT C;P;
<--  CCC
<--  HOST
<--  SIZE
<--  MDTM
<-- 211 END
feature SIZE supported
feature MDTM supported
--> SYST
<-- 215 Windows_NT
send_reply, failed: 0
register_mount_callback, mount_reply: 0x112bd30, error: (nil)


backend_dbus_handler org.gtk.vfs.Mount:QueryInfo
Queued new job 0x1130040 (GVfsJobQueryInfo)
--> NOOP
<-- 200 NOOP command successful.
send_reply(0x1130040), failed=0 ()
backend_dbus_handler org.gtk.vfs.Mount:QueryInfo
Queued new job 0x11300e0 (GVfsJobQueryInfo)
--> NOOP
<-- 200 NOOP command successful.
send_reply(0x11300e0), failed=0 ()
backend_dbus_handler org.gtk.vfs.Mount:QueryInfo
Queued new job 0x1130180 (GVfsJobQueryInfo)
--> NOOP
<-- 200 NOOP command successful.
send_reply(0x1130180), failed=0 ()
backend_dbus_handler org.gtk.vfs.Mount:QueryInfo
Queued new job 0x1130220 (GVfsJobQueryInfo)
--> NOOP
<-- 200 NOOP command successful.
--> CWD /
<-- 250 CWD command successful.
--> PASV
<-- 227 Entering Passive Mode (200,98,196,3,195,130).
--> LIST
<-- 125 Data connection already open; Transfer starting.
<-- 226 Transfer complete.
send_reply(0x1130220), failed=1 (File doesn't exist)
backend_dbus_handler org.gtk.vfs.Mount:Unmount
g_vfs_job_unmount_new request: 0x11368a0
Queued new job 0x1120580 (GVfsJobUnmount)
send_reply, failed: 0
unregister_mount_callback, unmount_reply: (nil), error: 0x11116a0
send_reply(0x1120580), failed=0 ()

Oh.... Actually the "%2Fsitecbr" is just a lftp misparsing of the (bogus) directory reply "/sitecbr", not ~sitecbr as I thought. "CWD /sitecbr" works!

This works:
gvfs-mount ftp://sitecbr@ftp.sitecbr.com.br/sitecbr/
gvfs-ls ftp://sitecbr@ftp.sitecbr.com.br/sitecbr/

So.... what remains:
+ "does the / in the URI mean SITE ROOT or INITIAL START DIRECTORY" as described in bug #560357
+ nautilus giving up if not being able to list root directory as discussed in bug #520399 and bug #551822.

Thanks for the bug report. Since all problems in this bug report but one should be fixed by now, I'm going to mark this as a duplicate of the first bug report of the remaining issue. Please feel free to report any further bugs you find.


*** This bug has been marked as a duplicate of 560357 ***