::ftpd's response to the LIST command should be
formatted similar to the output of "ls -l", including
owner and group values.  But when ftpd is run on
Windows, the owner and group fields are simply omitted,
causing the ftp clients I am working with to mis-parse
the response.

I investigated how the ftp server at ftp.microsoft.com
formats its response to LIST, and I found that it uses
the generic literal strings "owner" and "group" to fill
the necessary fields.  So I patched ::ftpd to behave in
the same way.

The procedure ::ftpd::fsFile::fs needs the "list"
option of the switch command replaced with the following:

list {
    # [ 766112 ] report . and .. directories (linux)
    # Copied the code from 'nlst' above to handle this.

            foreach f [lsort $fileList] {
                        if {[string equal [file tail
$f] "."] || \
                                [string equal [file
tail $f] ".."]} {
                            continue
                        }
file stat $f stat
                        if {[string equal
$tcl_platform(platform) "unix"]} {
                            set user [file attributes
$f -owner]
                            set group [file attributes
$f -group]
                        } else {
                            set user owner
                            set group group
                        }
    puts $outchan [format "%s %3d %s %8s %11s %s %s" \
            [PermBits $f $stat(mode)] $stat(nlink) \
                            $user $group $stat(size) \
                                    [FormDate
$stat(mtime)] [file tail $f]]

    }
}

Logged In: YES 
user_id=75003

Accepted and committed to head.

File Added - 103870: diff

Logged In: YES 
user_id=812825

i agree with the submitter, the format should be constant
across platforms. patch generated and attached.

Logged In: YES 
user_id=75003

Notes for future reports:

Note I: Setting the 'category' information will in many
cases auto-assign a maintainer for review and application.

Note II: Changes sources, or patches are best not inlined
into the bug report. Attaching them as separate files is
better for two reasons:

* The notification mails for the report are shorter, as SF
doesn't have to send all this code, only the comments.

* The changes are easier to get out of the report, via click
on links. Right now I can either try copy/paste a mangled
version out of the webbrowser, or I have to go to a
notification mail to get an unmangled version I'd rather
simply click on a link for the attachment.