ftp reading an empty folder
[1/8] from: dajoy:operamail at: 19-Nov-2001 14:49
When I try to read an empty ftp directory I get this
message:
** Access Error: Port none not open
** Where: parse-dir-list
How can I handle this error. I think in this case read
should return an empty list, not throw an error.
Daniel
[2/8] from: media:quazart at: 19-Nov-2001 15:23
I've had the same problems before...
Are you using an older version of view/core?
RT/support had told me they were aware and in the process of fixing it... a
few months ago...
-Max
[3/8] from: arolls:idatam:au at: 20-Nov-2001 19:53
> How can I handle this error. I think in this case read
> should return an empty list, not throw an error.
>
> Daniel
To handle the error, surround your reading
code like this:
if error? set/any 'err try [
list: read ftp-dir
][
; an error occurred
; set list to empty
list: copy []
]
Anton.
[4/8] from: dajoy::operamail::com at: 20-Nov-2001 15:21
> From: Media <[media--quazart--com]>
> Subject: [REBOL] Re: ftp reading an empty folder
>
> I've had the same problems before...
>
> Are you using an older version of view/core?
No, I'm using view:
core 2.5
view and vid 1.155.0
> RT/support had told me they were aware and in the process of fixing it... a
> few months ago...
They haven't done it yet.
Daniel
[5/8] from: max:quazart at: 20-Nov-2001 15:39
hum, I guess Its a question of the way some ftp servers respond to empty
dirs...
have you tried on another server?
The only thing I can suggest is that you enable network tracing :
trace/net on
and send a copy of the console output to rebol support ([feedback--rebol--com]).
This way, they'll be notified that the problem persists!
ALWAYS REMEMBER to remove all reference to sensitive user/password
information in the console's data before sending it at large, cause your
urls data will be printed in the net/trace data!
-MAx
[6/8] from: sterling:rebol at: 21-Nov-2001 17:04
What kind of server are you contacting? i.e. Unix, Windows, ... ??
Doe it fail on all servers or just a specific one?
Max had a problem some time ago, which was a failure between REBOLand
the Windows FTP server, and I thought it had been fixed in the current
version of /View. If it fails in /View, you could send in a network
trace,
trace/net on
read ftp://your-stuff-here
to [feedback--rebol--com]. If it's a public server that we can access,
we'd be in great luck but I'm guessing not. If it is just with a
Microsoft FTP server, it'll help if we know which one and which
version.
If you mail a trace in to feedback, fel free to scramble or remove any
of the login and/or server information since it's just the network
interaction that we care about.
Sterling
[7/8] from: sterling:rebol at: 21-Nov-2001 17:06
I looked up your feedback ticket and the notes say it was working in
the current version of /View. Is that correct or are you still having
problems?... just trying to get a handle on where things stand.
Sterling
[8/8] from: max:quazart at: 22-Nov-2001 7:57
I Sterling,
I guess this mail is addressed to me!
I have changed jobs since that feedback ticket so I can't test it anymore.
BUT If I remember correctly the version which had shipped a few days later,
did not solve the problem... (I'm pretty sure I'd send a report on that at
the time)...
Which is why I eventually did the try? thing to trap the error.
A note is that the system I was ftp'ing to was not a standard ftp windows
server setup. It was an ftp server based on windows but which transfered
the ftp down to an embeded device (a Digital Disk Recorder). I was doing
HDTV transfers of frames on this DDR (6MB files each, 200 images in total).
A part for the empty dirs, REBOL was doing great (performance).
Sorry I can't confirm anything... I don't have access to the DDR since I
don't work where one is available... unfortunately 200k$ devices don't lie
around here and there ;-)
HTH !
-Max