World: r3wp

I presume that the problem is just with the one server?

I think all of Romano's patches http://www.rebol.it/~romano/ftp-patch.r
were incorporated already.

Well, I haven't tried it with a different FTP server, but it definitely 
appears the problem is on the Rebol side.

I've considered installing WarFTPd or something, but this is a production 
server and I don't want to mess anything up by having two FTPd's 
installed simultaneously.

I'm not even sure it is an FTP issue.  The timeout should be triggered 
by Rebol's networking kernel, shouldn't it?

when it hangs, does it use CPU time?

(I meant "I'm not even sure it is a Rebol FTP protocol issue")

No it doesn't use any CPU time.  All stats on the process flatline. 
 No I/O, no CPU, no page faults.

This is part of the application I wrote called Smooth-Copy which 
I am using as a remote backup utility for some of my clients (and 
my wife's laptop, from which I got these results).

Also, I am using FTP in passive mode.

I am overwhelmed with projects presently, and I'm willing to pay 
if someone can come up with a patch to prot.r for FTP (if that is 
where the problem exists).  I would also allow the patched prot.r 
to be released back to the community.

the problem is that it may be just with a particular ftp server ...

But it seems the FTP server is working properly according to the 
log file.  If it cannot retrieve the directory listing, it sends 
a 425 and then eventually disconnects.  In any case, Rebol should 
never hang indefinitely even if the FTP server misbehaves.

Some FTP problems can be bypassed with:
system/schemes/ftp/passive: true
(Don't ask me why!)

We posted the complete source to our FTP client interface, you will 
find the code to handle most of this.

ftp-gadget i guess? http://www.rebol.org/cgi-bin/cgiwrap/rebol/view-script.r?script=ftpgadget-package.r
And  you can try it with the gui first :)

if not, can you make an account to trace and try?

Sunanda: Yes, I am running in passive mode.

Reichart: Thanks for posting the source code.  Unfortunately, it 
doesn't look like it can be used like the standard FTP protocol in 
Rebol as it is integrated with your GUI.

Shame.  I remmember when we had to build that, I had indeed asked 
it be made a module, so that suprises me,

I downloaded the source code and upon quick inspection, it doesn't 
look like I could use the FTP by entering ftp://user:[pass-:-server], 
but I could be wrong.

Bo, I've done a bit of FTP hacking. Maybe I can find the bug.

does  ftp-gadget work with your server by gui? eg is the ftp-part 
good enough? If not, where can we test against that server?

Probably because some servers require passive mode? ;-)

Bo: Also, I am using FTP in passive mode.

Bo: arent you behind firewall?

Oops, wanted to cite bo, ntoto address him. He said he  uses passiv 
modea while ago.

I do not know, if it will help you, but I check the cached connections 
in systems/schemes/ftp/handler/connections for any already closed 
connection before doing an ftp action.

is ftp-gadget still much better  then ftp? looks like  a module with 
gui-callbacks to me. and i spottet the word "async" somewhere.

if all [	

 lock: wait join copy [0:0:0.001] system/schemes/ftp/handler/connections 
 ; problems with closed, but still cached connections
	none? copy lock
] [
	close lock
	remove find system/schemes/ftp/handler/connections lock
]

is there a way to "trace" where you read or 'do'ed a file from? would 
be handy if you had a script that could tell whether it was run from 
a webserver or from a local disk

I don't think you can. But check system/options and system/script 
. You could also pass an argument in using do/args.

I think this could be really useful. In fact I think I'll RAMBO it. 
:-)

I agree. But be careful what you wish for.

security?

webserver, disk, random example or exactly that? becausewith  webserver 
(-c) you have stuff in the  cgi-object. Carl uses that  to decide 
 if it  is  a testrun.

The problem I'm having is that most FTP transfers work fine, but 
somewhere along the line (say after 50 FTP connections or perhaps 
as many as a couple thousand FTP connections) one of the connections 
hangs up (presumably because the FTP server returned an unexpected 
response, like not being able to open a directory).

I've set up an FTP user for testing on our server called "rebol3" 
with the password "rebol3".  This user has all permissions in its 
sandbox directory.  Feel free to test, but as I said, it may take 
thousands of FTP requests to get one that locks Rebol up.

if it is  because  of a response one could try to provoke such errors. 
with some luck..

url of that server?

Sorry for my lack of attention.  The URL is ftp://rebol3:[rebol3-:-69-:-12-:-157-:-73]/

a special  version of rebol, or with everyone?

I'm using the prot.r from SDK-2-6-2.

unusual filenames? since it hangs when getting  the  directory?

Volker, I presume that is you connecting to the FTP server.  You 
got two 425 errors from the server the first two times you connected. 
 That's the same part where Rebol was hanging up for me.

It could be due to unusual filenames, but it doesn't always lock 
up on the same file.

And are you sure you don't have bad FTP server?

filezilla got errors too.What triggeredt hem? server full?

No.  I may have a bad FTP server, but I am still concerned that Rebol 
would lock up even if the FTP server was bad.

That directory currently has 26.1GB free.

i meant to many  users. because filezillas connectiong was  rejected.