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