Textual unix owner and group display for the MLSx output

[GoogleCodeExporter]

Lets see if I have better luck with this suggestion...

Even though 
http://www.iana.org/assignments/os-specific-parameters/os-specific-parameters.xm
l is sadly empty (!?) it seems that several FTP servers offer UNIX.owner and 
UNIX.group (optional) facts for the MLST/MLSD command. The attached patch adds 
these OPTSional FEATures ;) to pyftpdlib.
The id->name conversion code was lifted directly from the get_user_by_uid and 
get_group_by_gid functions.

Original issue reported on code.google.com by gc...@loowis.durge.org on 22 Mar 2011 at 6:12

Attachments:

• mlsx_owner_group_fact.patch

[GoogleCodeExporter]

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.

Original comment by gc...@loowis.durge.org on 27 Mar 2011 at 12:22

Attachments:

• mlsx_owner_group_fact2.patch

[GoogleCodeExporter]

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.

Original comment by g.rodola on 30 Mar 2011 at 11:17

[GoogleCodeExporter]

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

Original comment by g.rodola on 4 Jan 2012 at 12:45

[GoogleCodeExporter]

I don't know why proftpd works that way either.
Unfortunately 
http://www.iana.org/assignments/os-specific-parameters/os-specific-parameters.xm
l (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.

Original comment by gc...@loowis.durge.org on 4 Jan 2012 at 1:17

[GoogleCodeExporter]

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.

Original comment by g.rodola on 4 Jan 2012 at 1:45

[GoogleCodeExporter]

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.

Original comment by pri...@gmail.com on 27 Apr 2013 at 5:10

[GoogleCodeExporter]

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. 

Original comment by g.rodola on 27 Apr 2013 at 5:15