Novell/Excelan ftpd bug--workarounds?

Steven Souza souza at optigfx.optigfx.com
Thu Nov 8 08:31:49 AEST 1990


Try this:

(1) Open an ftp connection to a machine running "LAN Workplace for
SCO Xenix/386".

(2) On the remote machine, use pstat to examine the open file table of 
the ftpd process spawned to service your ftp session (use "ps -elaf"
to get the process address to supply "pstat -u").  It will be owned 
by the user-id used for the ftp-login.  You should see 4 or 5 non-zero 
(i.e. open file) entries in the 6x10 slot table.

(3) Go back to the originating machine and type a few "ls" or "dir" 
commands to the ftp client process.  Repeat (2).

What you find is that the open file table accumulates new entries,
but does not free them.  Eventually (after ~ 60 "ls" commands), the
connection stops working.  To continue, you need to quit and re-
establish the ftp connection.

We have an application that uses an on-going ftp session similar
to this scenario, but it eventually uses up all 60 per-process
files on the remote end.  We've spoken to Novell, they've acknowledged
the problem, but will not help.  Apparently the code (v3.7) is
"frozen" and will not be supported anymore.

The question:  Are there any existing patches or workarounds out 
there for this problem?  I know it's a longshot, but are there any
public domain versions of ftpd?

Any help would be MUCH appreciated!

Thanks,
Steve Souza	Optigraphics Corp.	souza at optigfx.com	619/292-6060



More information about the Comp.unix.xenix.sco mailing list