Changed FTPD.
OUTWATER ~ KEITH J /5G3110
vac4050 at cae597.rsc.raytheon.com
Thu Jan 11 19:55:57 UTC 2001
Ditto. They're real handy.
BTW Jake, is there any pratical way to eliminate the requirement to specify the
buffer size for the hooks? Could it be dynamically allocated and be allowed to
grow to the system memory limits?
Keith
>
> This all sounds very good to me! (as long as you keep the FTP
> hooks in there, I'm happy -- I don't know about others, but I
> do use them)
>
> Jake
>
>
> On Thu, Jan 11, 2001 at 10:05:44PM +0300, Sergei Organov wrote:
> > Hello,
> >
> > I've finished a bunch of changes to the RTEMS FTP server. If the changes
seem
> > to be promising, I'll be glad to submit them to RTEMS maintainers.
> >
> > Here is the list of changes:
> >
> > - use pool of pre-created threads to handle sessions instead of
> > creating/deleting threads on the fly
> > - LIST output is now similar to what "/bin/ls -al" would output, thus
> > FTP clients such Netscape are happy with it.
> > - LIST NAME now works (both for files and directories)
> > - added support for NLST, CDUP, and MDTM FTP commands to make more FTP
clients
> > happy
> > - keep track of CWD for every session separately
> > - ability to specify root directory name for FTPD in configuration table.
FTPD
> > will then create illusion for FTP clients that this is actually root
> > directory.
> > - ignore options sent in commands, thus LIST -al FILE works and doesn't try
to
> > list "-al" directory.
> > - buffers are allocated on stack instead of heap where possible to eliminate
> > malloc/free calls (avoid possible heap fragmentation troubles).
> > - drop using of task notepad to pass parameters - use function arguments
> > instead
> > - use snprintf() instead of sprintf() everywhere as the latter is unsafe
> > - use of PF_INET in socket() instead of AF_INET
> >
> > Here are ftp clients I've tried new FTPD with
> > (all of them running on Debian GNU/Linux 2.2):
> >
> > Lftp 2.1.10
> > NcFTP 2.4.3
> > Netscape 4.75
> > ftp
> > mc 4.5.49
> >
> > BR,
> > Sergei Organov.
>
More information about the users
mailing list