1  |   Order by index

May 26, 2004, 3:36am

I can't send files via awbrowser ... I can receive but not send. Can anyone
advize me on how to fix this? I'm using Win XP Pro for which TCP port 3000
is enabled for incoming and outgoing and Zonealarm Pro which has been set to
allow file transfers in aw. I'm stumped!

LNH



--

May 26, 2004, 7:29am

Check aworld.ini, I've had that problem before when the path in
[transfer]
recv_dir=

did not exist. The standard path points to the INCOMING folder in
your AW browser folder, for example
recv_dir=c:\Active Worlds\incoming

Alex

On 26 May 2004 01:36:16 -0400, "lady nighthawk"
[View Quote] >I can't send files via awbrowser ... I can receive but not send. Can anyone
>advize me on how to fix this? I'm using Win XP Pro for which TCP port 3000
>is enabled for incoming and outgoing and Zonealarm Pro which has been set to
>allow file transfers in aw. I'm stumped!
>
>LNH

May 26, 2004, 11:08am

[View Quote] > I can't send files via awbrowser ... I can receive but not send. Can anyone
> advize me on how to fix this? I'm using Win XP Pro for which TCP port 3000
> is enabled for incoming and outgoing and Zonealarm Pro which has been set to
> allow file transfers in aw. I'm stumped!
>
> LNH
>
>
>

This is a well known bug in the browser - on some cable/DSL connection it just doesn't work :(

--
Andras
"It's MY computer" (tm Steve Gibson)

May 26, 2004, 11:09am

[View Quote] [View Quote] See the thread : news://news.activeworlds.com:119/3eb9577d$3 at server1.Activeworlds.com

--
Andras
"It's MY computer" (tm Steve Gibson)

May 26, 2004, 12:58pm

What nowhere is mentioned, btw: you cannot store received files in the
root directory, when a root is set as the default (or from the last time
you have _sent_ a file), receiving will always fail.

There are more oddites though - I have 2 computer on the same switch,
but connected to the internet via different gateways. Both computers and
both gateways are set up exactly the same and I can send files from A to
B, but not from B to A <g>.


[View Quote]

May 26, 2004, 1:42pm

[View Quote] A certain tourist ;) suspected that the receiver tries to connect
before the "Y" reply goes through to the sender, especially with fast lines.
Might be better if the sender was connecting to the receiver anyway.
There could be some buffer overflows too.

--
Mauz
http://mauz.info

May 26, 2004, 3:31pm

How odd, I tried to change that but when I logged in aw changed it back to
what it was ... I even tried leaving it blank after the next try and aw
again changed it back to what it was. Either way I still can't send. And ya,
I was on satellite and now I'm on cable ... but even on satellite it worked
for quite some time and then one of the recent upgrades it just stopped
working. So part of the time on satellite it didn't work (but for the most
it did) and now on cable it's not working. AW won't let me change that line
in INI. Thanks all for your input ... I'm still at a loss tho, unless it's
an aw bug as previously mentioned.

LNH


--

[View Quote]

May 26, 2004, 3:48pm

Probably you have tried to put in a non-existing directory - you also
can manually set up the ini file section like:

[transfer]
send_dir=C:\awfiles
recv_dir=C:\awfiles
file_type=4

This requires that you have already a folder named awfiles on your C:
drive. Make also sure that there are no other [transfer] sections in the
ini file.

When you do not want to edit the ini file, just let someone send you a
file and, before transmission starts, manually select a folder to store
that file into, eg. C:\awfiles (must exist already). After that and when
you log out, the line in aworld.ini will have changed to the selected
folder.




[View Quote]

May 26, 2004, 8:39pm

The directory I tried was valid ... but I'll try your suggestion next.
Someone did say in a previous thread that this was an aw bug that happens on
some DSL / cable connections, that does apply to me. Thanks again...

LNH



--

[View Quote]

May 27, 2004, 1:43pm

[View Quote] Reply from the tourist (tourists can read these newsgroups? neat):
"I have totally shattered that theory. The sender opens a listening socket long before.
The code is awful, it's hard to reproduce the problem locally, and well...
I firmly believe this feature should either be removed from the browser or rewritten from scratch anyway."

--
Mauz
http://mauz.info

1  |   Order by index