[Oberon] Re. FTP.

easlab at absamail.co.za easlab at absamail.co.za
Mon Jun 14 14:03:13 CEST 2004


Peter E. wrote:-
> FTP.Open peter at carnot.pathology.ubc.ca
> reports
> ProFTPD 1.2.5rc1 Server (Debian) [carnot.pathology.ubc.ca]
> ..

It looks as if it connected.
Do you know/confirm that it 'echoes' fully and correct 
eg. by comparing with another client?

> FTP.CurDir
> reports
> "/home/peter" is current directory.
> 
> FTP.Dir 
> reports
> -rw-r-----   1 peter    peter        1868 Sep 17  2003 AusoniaChuck
> drwx------   3 peter    peter        1024 Sep  6  2003 Desktop
> -rw-r--r--   1 peter    peter        1503 Apr  9 19:48 DiskLayout
> drwxr-xr-x   5 peter    peter        1024 Nov  5  2003 GNUstep
> -rw-r--r--   1 peter    peter       22670 Apr  3 03:33 Holder.Vinci
> and the mouse is frozen.  There are many more files in 
> /home/peter than these 5.

I would expect this if eg. the 'connection broke'.

> Control+Break Control+Break  yields this trap.
> TRAP 13  Keyboard interrupt (PC Native 05.01.2003)
> Input.UnsafeBreak  PC = 14105
> 	note1 = "Warning: Interrupting a module"
> 	note2 = "may invalidate its invariants"
> 	note3 = "and make it unstable."
> NetTCP.Poll  PC = 11775
> 	item =  004BD520H
> 	port =  003780A7H
> NetTCP.Receive  PC = 12449
> 	C =  00508960H
> ....
Can you do some other inet-command after 'freeing yourself from
the FTP loop'.

I often forget to do FTP.Close , and then next time on line I can't do
further FTP commands.    Only recently did I find a 'work-around'
[since I can't afford to do M$ (reboot)]: 
 something-like System.Free FTP

> Mac Anarchie has no difficulty connecting to 
> ftp://carnot.pathology.ubc.ca and transferring files.
> 
> Any ideas about this?  

My strongly held opinion is:
* the developer of inet utilities tests it against his available
   facilities [eg. his ISP] and not against a 'test harness'.
* I've found 2 incompatibilities with the relevant RFCs
     1. login, userID,
     2. email TextMail.Directory .
*  If you USE NO's facilities you will find stuff to fix: those
      who claim 'there are no problems', are those that don't 
      use it.
*  A major factor in reducing negative EFFECTS of such inevitable
    problems is sociological rather than technical. I.e effective 
     collaboration mechanisms to help weed out the bugs.

Have we got formal methods to eg:
* accumulate problems on a module, until it justifies some
   one attacking it,
* a division of labour mechanism for reporting, investigating,
     patching, retesting ...., or do we just "do it" ?

== Chris Glur.

PS. the System.Free FTP work-around is great for me.
  I wish I had one for disabling fd0-diskette when it sees a problem
  instead of pulling out its power lead until I re-boot.
One doesn't want to leave the diskette-mechanism grinding away
for days/weeks before the next re-boot ?





More information about the Oberon mailing list