Because Nautilus has recently been rewritten in GVFS I've checked to see if this bug is still reproducible. I can confirm this bug report is still valid. I'd appreciate a response, because it has been longer than a year ago since I first filed this bug report.

Hi Alexander, thanks for trying the new version of Nautilus and updating the status of your bugs.
I can reproduce this bug too, so I'm confirming it. CC-ing Benjamin.

Yeah, there's some fiddling required to extract permissions from FTP servers and gvfs doesn't attempt to do this yet.

I'd really be happy if this is implemented. It's the last reason for the crappy gftp on my system ...

*** Bug 334955 has been marked as a duplicate of this bug. ***

I'm looking forward of this enhancement too! Can we help the development anyhow?

September 2009, sadly still no progress to this...

Yeah, it seems noone wants to implement directory parsing in a maintainable way.

The only patches I've seen were modifying ParseFTPList.c and I want to keep that file as close to Mozilla's version as possible, because that file is not something I want to maintain. So I rejected the patch.

What should happen is that someone writes a GVfsFtpDirFuncs (see daemon/gvfsftpdircache.h) implementation for ls-style output that does not rely on the Mozilla code. The Mozilla code is only interested in the name and size of the file - so we only provide that. This implementation could then support parsing permissions, uid/gid etc.
Or someone could write a GVfsFtpDirFuncs implementation that supports MLST style directory listings.
Be warned though, that this is a non-trivial endeavour.

I've looked at various FTP clients (wget, WebKit, Filezilla, gftp, ...) and their implementations were either tremendously complex, not license compatible or didn't implement permissions either, so I didn't use them.

Are you sure about gftp ? It looks like it's written in C, under GPL and it's managing perms, don't know about complexity.

But anyway, reusing the gftp dir parser would be great :)

Needs to be LGPL or compat. to be used in GVFS, else we'd just rip the relatively well-maintained FTP-list parsing code out of GNU wget.

Thats not quite correct. For the backend side of gvfs, GPL is possible, for instance libsbmclient is GPL. This is ok since apps are isolated from the backend process using a generic protocol with multiple implementations.

So we could use the wget parser, that would be great if somebody could do that :)

First of all, I have no clue about the quality of wget's parser. wget is not really known as a good FTP client. In particular I've never used wget to modify file permissions.
Second, while LGPL is not a hard requirement, I have a strong preference towards LGPL. The main reason here is not gvfs, but libsoup or other web-related libraries that might want to include FTP functionality in some form and they are LGPL.

But in the end, the important thing is that someone provides code _and_ maintains it when somebody finds bugs with weird FTP servers.

Hi all,
I also happen to be quite interested in gvfs’s full FTP support, and I have previously written HTTP, SMTP and FTP clients from scratch (as bot helpers for my PHP web sites).

I’m willing to rewrite the involved code entirely, as long as someone can give me some pointers regarding facilities the code is allowed to use, and (compatibility) criteria the resulting code is supposed to meet. And of course, I’ll need people with a broader FTP server knowledge than mine (for their quirks).
The only problem is I’m only mildly experienced with GTK+, but I do know my way with C.
Yes, I do see the message above, but it’s 6 months old now, so I want to make sure the pointers there are still valid.

So, let me know if someone is interested in getting me started.

Yeah, what I said in comment 8 is still pretty much accurate.

Okay, so I did take a look at the files you mentioned.

I’m not sure I understand what you previously wrote: would it there be any need to rewrite any code other than the big parser by Mozilla?

I’m asking, since the mangling of LIST output I can totally rewrite from scratch, no matter how complicated and special-cased, provided I’m given enough examples; on the other hand, rewriting the gvfs implementation will require me to study how several things work, since the names don’t tell me much, and I assume to fully understand them I’d have to study gvfs from a more generic standpoint, seeing how the caching works, in what order functions get called... something paradoxically more complicated, for me, than just rewriting the parser.
Not that I’d not do it, I just want to make sure I’m not doing unnecessary work.

So here's the constraints:

1) The mozilla code must not be touched. It's ugly and there's noone who really understands what it does. We totally trust Mozilla to keep that one file updated and security-reviewed. And we trust them to make sure it works with virtually all FTP servers in the world. So we want a new parser.

2) There is no testsuite or examples or anything for the LIST parser. This isn't needed because we trust Mozilla's code (see above). So you will not be able to parse every listing with the new parser. So we need a way to say "hey, this parser doesn't work for this FTP server, let's take the Mozilla one" and fall back to the old one.

3) Most parsers contain code that is very hard to read and maintain. I'd be very happy if someone writing one would take of that. Also, this code is very security sensitive (just like all parsers everywhere) and I'd like a design that's careful about that, too.

So what I'd expect someone to do is write a parser that works for initially just one server, detects failures to parse and then falls back to the Mozilla one. Then we can enhance that parser later with new functionality.


That said, there's not a lot of code you need to write. Basically, it's just the process function. And you can have a look at g_vfs_ftp_dir_cache_funcs_process() to see how the current one works.

Created attachment 169163 [details] [review]
Patch to parse attributes from POSIX ls -l compatible LIST output

The above patch for gvfs v1.6.1 enables file attributes to be read by Nautilus.  To set the attributes requires a further simple addition.  If there is interest I can provide another patch.

The patch is to gvfsftpdircache.c and only adds code to the function g_vfs_ftp_dir_cache_funcs_process().  This should make the patch easy to maintain.

I hit the issue of Nautilus not beeing able to see and edit file permissions. What is the status on this bug?

Lawrence: It would certainly be nice if you could attach your patch for storing here too. Just for others to try...

I use the following patch, which adds attribute r/w capability, to gvfs v1.6.4.  Works great on Ubuntu 10.04 to maintain my web server.

Created attachment 179086 [details] [review]
Add ftp file attributes

For gvfs 1.6.4

Applies cleanly against gvfs-1.6.6-1.fc14.i386 on my Fedora 14 system. If somebody wants to test I can provide an F14 src.rpm.

I have just tested it and verified all modifications by gftp, it works perfectly for me.

@Benjamin? Any chance to have this included?

Woah, that patch is cool. I like it. In particular because it doesn't modify the parser. Why did I not notice that in August?

One thing though: Is there a way to detect chmod support? I don't want to advertise it when it's not supported and the patch seems to always advertise it.

On http://www.phpbuddy.eu/ftp-klasse.html there is a FTP class.

It checks for for the Server OS as in case of WIN there is no SITE CHMOD support. 

More information on http://www.xav.com/scripts/installer/3008.html

This is the log of not supportted CHMOD: http://www.smartftp.com/support/kb/site-chmod-errors-f18.html.

commit 7ad211bf67c3953f349e4adf911cce8c630e4890
Author: Lawrence Rust <lvr@softsystem.co.uk>
Date:   Mon Jan 24 02:54:19 2011 +0100

    ftp: Implement chmod
    
    https://bugzilla.gnome.org/show_bug.cgi?id=416221

commit 6da46f05d75a2017d1fb745ab389c7ad1019e4ad
Author: Lawrence Rust <lvr@softsystem.co.uk>
Date:   Mon Jan 24 01:26:24 2011 +0100

    ftp: Parse mode, user and group for unix listings
    
    https://bugzilla.gnome.org/show_bug.cgi?id=416221

commit 9a4f327cdc9dde66e7417c2c4b426d936b407f02
Author: Benjamin Otte <otte@redhat.com>
Date:   Sun Jan 23 23:55:01 2011 +0100

    ftp: Parse SITE HELP output to detect chmod support
    
    Support for it will come in later patches.
    
    The patch also detects chgrp support, but we're not intending to use it
    yet.

Just FYI: It would have been nice if the patch had been closer to the glib coding standards. The biggest issue I had was with the reversal in checks. Nobody says "if 2 is the response group", everyone says "if the response group is 2", so "if (2 == RESPONSE_GROUP (res))" doesn't read very fluently.
And the "might write = instead of == accidentally" argument doesn't hold anymore these days either, because gcc catches that.

Oh yeah, one last comment:
I implemented the feature check for chmod using the "SITE HELP" command. I checked vsftpd, pure-ftpd, proftpd and ms-ftpd, and implemented something that can parse all those outputs. If there's other servers where this detection method does not work, please open bugs about them.

On gvfs 1.8.1 (Ubuntu Oneiric) setting ftp permission doesn't work. It the feature been implemented in it?