On 10/1/2011 11:09 AM, Jim Hall wrote:
> I uploaded my file successfully, but wasn't able to complete my download:
>
>
Jim,
Please try it again - we have a common enemy, and it is my ISP.
I've tested this with files as large as 170MB under DOS 5. I'm sure it
will work if the connection stays u
Op 1-10-2011 18:09, Jim Hall schreef:
> I uploaded my file successfully, but wasn't able to complete my download:
Lots of servers are set to an INCOMING directory first, with only being
allowed to upload to the server. Admin checks files afterwards and moves
them to some /PUB directory to make i
On Sat, Oct 1, 2011 at 10:42 AM, Jim Hall wrote:
>>
>> Good test, but it is running DOS 3.3. You ran that drive out of disk
>> space, and it recovered gracefully ...
>>
> [..]
>
> My intention was to test your ftp server's ability to manage large
> files, and that the downloaded file matched the
On 10/1/2011 10:54 AM, Bernd Blaauw wrote:
> Are there quota enforced in your FTP server?
> * 2GB/4GB per file
> * total storage allowed for FTP server's data directory
> * speed?
> * etc
>
> Let's say FTP server is only allowed to
> * store 100GB on a 2TB disk. 0
> * Meanwhile each IP 50GB max (li
On Sat, 2011-10-01 at 09:04 -0500, Michael B. Brutman wrote:
> The bug is simple - if there is a data connection already open and the
> PASV mode port changes, you have to close the existing data connection
> *and* recycle the socket. I missed the second part in a few cases, and
> that bug has
Op 1-10-2011 17:39, Michael B. Brutman schreef:
> Good test, but it is running DOS 3.3. You ran that drive out of disk
> space, and it recovered gracefully ...
Are there quota enforced in your FTP server?
* 2GB/4GB per file
* total storage allowed for FTP server's data directory
* speed?
* etc
L
>
> Good test, but it is running DOS 3.3. You ran that drive out of disk
> space, and it recovered gracefully ...
>
[..]
My intention was to test your ftp server's ability to manage large
files, and that the downloaded file matched the file I uploaded. I
will try again with 10MB file, which would
:-)
We'll call this a successful test of "ftp server can detect when disk is full".
On Sat, Oct 1, 2011 at 10:23 AM, Bernd Blaauw wrote:
> Op 1-10-2011 17:19, Jim Hall schreef:
>> I created a 100MB file full of binary zeroes, but wasn't able to
>> transfer the whole file to your ftp server:
>
>
On 10/1/2011 10:19 AM, Jim Hall wrote:
> I created a 100MB file full of binary zeroes, but wasn't able to
> transfer the whole file to your ftp server:
>
>
> ftp> put 100mb.dat
> local: 100mb.dat remote: 100mb.dat
> 227 Entering Passive Mode (96,42,66,188,11,35)
> 150 BINARY type File STOR started
Op 1-10-2011 17:19, Jim Hall schreef:
> I created a 100MB file full of binary zeroes, but wasn't able to
> transfer the whole file to your ftp server:
funny that, considering it's likely a 8086 running the FTP server
program, thus tiny harddisk.
> -rwxrwxrwx 1 ftp ftp 16564224 Oct 1 10:12 100
I created a 100MB file full of binary zeroes, but wasn't able to
transfer the whole file to your ftp server:
ftp> put 100mb.dat
local: 100mb.dat remote: 100mb.dat
227 Entering Passive Mode (96,42,66,188,11,35)
150 BINARY type File STOR started
550 Filesystem error
ftp> ls
227 Entering Passive Mod
Alex,
All testing is worthwhile ... the client you have that gets the 425
error messages made me suspicious that I was losing socket data
structures, and after 3 days of testing I was able to confirm that was
happening.
The bug is simple - if there is a data connection already open and the
P
Quoting Bernd Blaauw :
> Is your machine on the internet or did you perform some router port
> forwarding magic? I've always wanted to do that, however router software
> isn't that cooperative usually.
The machine is behind a firewall and the firewall is setup to forward
incoming requests on po
Op 29-9-2011 15:37, Michael B. Brutman schreef:
> All if this will be part of the next mTCP release, which I'm targeting
> for the next week. Getting some testing time on it is a good thing ...
I wonder if all of FlashFXP's abilities (FTP, FXP, SFTP, FTPS) work.
iPXE project has some interesting
Hi Michael!
I played around with Filezilla and Cyberduck on my Mac. Everything
seems to work OK for me. That's really great! Made some test
directories and browsed through them. I forgot that DOS directory
names are limited to 8 letters, got a "550 Bad path" and nearly blamed
you for it ;-)
I
On Thu, 2011-09-29 at 14:14 -0500, Michael B. Brutman wrote:
> Interesting bug. I thought that this would be an easy catch, but it is
> more subtle than I thought. I can't recreate it here.
>
> Your client sends a PASV command before attempting to put the file,
> which is the correct behavior
Alex,
Interesting bug. I thought that this would be an easy catch, but it is
more subtle than I thought. I can't recreate it here.
Your client sends a PASV command before attempting to put the file,
which is the correct behavior. Under normal circumstances that just
tells the server to sta
It's DOS so the filename was in error, but it should have aborted the data
transfer fully. I'll look into that after work - for now stick to 8.3 style
filenames.
Single Stage to Orbit wrote:
>On Thu, 2011-09-29 at 08:37 -0500, Michael B. Brutman wrote:
>> I have made a large round of improvem
I'll have to install those clients and try them. But it is most likely to be
something specific about them.
Anonymous users can't delete what they (or anybody else) upload. So that was
expected behavior.
Mike
escape wrote:
>Works with Filezilla/Linux, lukemftp, ncftp, but fails to retrieve
Works with Filezilla/Linux, lukemftp, ncftp, but fails to retrieve
directory listing in Midnight Commander, Krusader and Dolphin - upon
connection shows empty filelist. Also I was unable to delete file
TEST.TXT uploaded to /INCOMING, despite its rwxrwxrwx permissions, but I
suspect this could be so
On Thu, 2011-09-29 at 16:27 +0200, Robert Riebisch wrote:
> Single Stage to Orbit wrote:
>
> > ftp> put alex_was_here
>^
> I guess LFNs are not supported.
Works fine for 8.3 files:
$ ftp -n -p 96.42.66.188 2021
Connected to 96.42.66.188 (96.42.66.188).
220 mTCP FTP Server
On Thu, 2011-09-29 at 16:27 +0200, Robert Riebisch wrote:
> Single Stage to Orbit wrote:
>
> > ftp> put alex_was_here
>^
> I guess LFNs are not supported.
I guess I've forgotten DOS can be quite anal about LFNs ;)
--
Tactical Nuclear Kittens
---
A quick test with ws_ftp PRO seems to be fine.
> -Original Message-
> From: Michael B. Brutman [mailto:mbbrut...@brutman.com]
> Sent: Thursday, September 29, 2011 9:38 AM
> To: freedos-user@lists.sourceforge.net
> Subject: [Freedos-user] FTP Server testing needed
>
Single Stage to Orbit wrote:
> ftp> put alex_was_here
^
I guess LFNs are not supported.
Robert Riebisch
--
BTTR Software
http://www.bttr-software.de/
--
All the data continuously generated in your
Michael B. Brutman wrote:
> I have made a large round of improvements to the FTP server in mTCP and
> I am looking for a little testing help with it. If you have a few spare
> moments over the next day or two just try to connect to it and browse
> the file structure. Using a few different cli
On Thu, 2011-09-29 at 08:37 -0500, Michael B. Brutman wrote:
> I have made a large round of improvements to the FTP server in mTCP and
> I am looking for a little testing help with it. If you have a few spare
> moments over the next day or two just try to connect to it and browse
> the file str
Works with Firefox.
Bye
Flo
El Thu Sep 29 15:37:45 2011, Michael B. Brutman escribió:
>
> I have made a large round of improvements to the FTP server in mTCP and
> I am looking for a little testing help with it. If you have a few spare
> moments over the next day or two just try to connect to i
I have made a large round of improvements to the FTP server in mTCP and
I am looking for a little testing help with it. If you have a few spare
moments over the next day or two just try to connect to it and browse
the file structure. Using a few different clients will help me shake
out any n
28 matches
Mail list logo
