Updated version of the patch to work with the post- r845 version of 
format_mlsx().

And a bit more of an explanation:
If running pyftpdlib on a unix-ish platform (one where the pwd and grp modules 
are import-able) you can use the "OPTS MLST ...." command to 'turn on' the 
output of the (numeric) 'unix.uid' and 'unix.gid' facts for the MLST and MLSD responses.
This patch also adds the textual facts 'unix.owner' and 'unix.group' as extra 
optional MLSx facts.

It seems a good idea to me, I just wonder why other FTP server implementations 
such as proftpd and pureftpd don't have such a feature.
Also, I'm a little worried about portability problems with filesystems not 
having a concept of file owner/group.
I'll have to think about this.

Little update.
From http://www.proftpd.org/docs/modules/mod_facts.html :

<<
Question: Why does MLST show the UIDs/GIDs for listed files, where LIST/NLST 
show the user/group names?
Answer: The list of "facts" defined by RFC 3659 does not include a fact for the 
stringified version of user/group owner names, unfortunately. This means that 
the MLSD/MLST commands don't have a good way of obtaining the user/group names.
To work around this issue, you can add the following to your proftpd.conf:

  <IfModule mod_facts.c>
    FactsAdvertise off
  </IfModule>
This tells proftpd to not advertise to the client that it can support the 
MLSD/MLST commands.
>>

So, it seems the way of proftpd to circle around this problem is to drop MLSD support.
Honeslty I'm not sure why they did that.

With FactsAdvertise == on:

250-Start of list for /home/giampaolo
250-modify=20111212093353;perm=fle;type=dir;unique=803U2;UNIX.group=0;UNIX.mode=0755;UNIX.owner=0; /
250 End of list

With FactsAdvertise == off:

250-Start of list for /home/giampaolo
250- /home/giampaolo
250 End of list

I don't know why proftpd works that way either.
Unfortunately 
http://www.iana.org/assignments/os-specific-parameters/os-specific-parameters.xml
 (which is supposed to define a set of "standard facts") has never ever been 
updated, so each FTP server is free to do whatever it likes in terms of 
OS-specific facts :-(

I still stand by my mlsx_owner_group_fact2.patch though - in terms of 
portability it doesn't do anything that the non-MLSx code isn't already doing, 
and these are all optional facts that have to be specifically requested anyway.

I believe the reason why RFC-3659 does not provide textual users/groups is 
because the string can contain ";", " " or "\r\n".
All 3 of them collide with standard MLSX representation.
I think your patch would be ok 99% of the times as UNIX systems won't allow you 
to create users/groups with such characters in the first place.
My only concern is what's gonna happen on customized filesystem and the fact 
that apparently there are no other FTP servers doing this.

The Python calls to lookup textual users & groups can be slow with very large 
user and group files; it is usually implemented as a sequential file search of 
/etc/passwd and /etc/group.  Maybe this is a reason to omit textual uid/gid, 
especially with the single thread version of pyftpdlib.

That would be mitigated by the fact that we process only 20 files at a time and 
then "yield", passing the control back to the main IO loop. I don't fear 
blocking. On the other hand I'm still not convinced this is a good idea though.