souza@optigfx.optigfx.com (Steven Souza) (11/08/90)
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@optigfx.com 619/292-6060