[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