jftp does not interoperate well with this ftp server:
(some message about "Not a directory: /")
Logged In: YES
So, what is happening here is that you have been using this
with this FTP server software and have found that this error
message keeps coming up? Does it happen every time to
connect to this kind of server?
From the error message that appears in the logs, it appears
that there may be something wrong with the way directory
data is parsed there. After looking for what could cause the
exact error message here to come up, what I have found is
that it is an error in that is coming up when directory
listings are being initialized. For this to come up, there
had to have been an exception thrown in the init() method in
DirLister.java. So for us to find out exactly what is
happening here, what would help very much would be a
stacktrace. You might have noticed something about an
exception being thrown, and if not, you'll need to check the
Java console. And from there you should see the exact
line(s) of code that are causing this. And copying and
pasting that here would help us very much in determining
what could be wrong here.
Logged In: YES
Here's a stack trace:
net sf.jftp.gui.DirLister.<init>: 56
Thanks for sending that stack trace. It did help give me an
idea of what is happening here, but there is some more
information that I will need.
What we seem to have here is an issue where when the remote
directory's contents are first displayed, but there is some
data on the contents of the directory that it is not
receiving. For each file in the directory to be displayed,
it should get the size of each file, and the permissions
that have been assigned to it. And from what I see the
section of DirLister.java code that is leading up to this
exception, the way this exception could be thrown is if not
all files in the directory have a corresponding size and/or
set of permissions. What happens is that it goes through
each file in the directory, and each filename is entered
into an array, and the corresponding sizes and permissions
are entered into two other separate arrays. But when it goes
through each file, the number of sizes and permissions
assigned to each must be equal to the number of files. If
not, it'll get to a point in a loop where it'll look for a
value that is outside one of the arrays' boundaries. And
that's what we appear to have here.
I would say that the quickest way of determining this would
be to check the .sortls_out file and compare it to what is
in the .sortsize_out and .permissions_out files that are
created in the .jftp directory just before this exception is
thrown. You might want to check how many lines are in each
one. You may find that one or both of .sortsize_out and
.permissions_out to see if they have fewer lines than
.sortls_out. I should note that these files are created just
before this exception is thrown, so maybe you can just run
"wc -l" on each of these files any time after this occurs.
When I've done that in the testing I've done, it always
comes up equal for each of these three files.
So this leads to my next questions. Does it always do this
every time you connect to any server running this server
software? And does it happen regardless of which platform it
is installed on? What would be quite helpful is if you know
of a server that we could log onto anonymously to test this
out ourselves. Also, I checked out that URL you mentioned
and downloaded the source code to the server, and I could
look there for some ideas on what may be happening here. But
I could always check our code first, and in fact I do think
there could be a patch applied fairly easily as a way of
getting around this if it is just not able to get some
permissions. But we'll see. We'll look into this further,
and hopefully find a way of getting around this.
The server is free, so you can always download it and run
My last comment seems to have got somewhat truncated. I was
suggesting to test it against some sort of test suit, that
could be developed. For example, a standard directory of
files and a unit test procedure to collect output.
Ithink the problem maybe to do with filenames containing spaces.
Well, as you suggested, I downloaded a copy of the FTP
server software, ran it, and was able to connect to it. I
also checked a number of directories, some of which
contained files that had spaces in them. I was also able to
download files as well, some of which had spaces in the
filename, except one that led to an exception being thrown.
Perhaps I can post the stack trace of that later on, if it'd
help. But there may be some parsing issues here.
What is interesting here is that this file that caused the
exception was one that I was able to upload to a different
server, then I didn't have any problems downloading it back.
This suggests there may be some parsing issues with the
server software. But have you used other FTP clients with
this server you are trying to connect to?
And here's something else I can suggest: Before opening an
FTP connection to this server, make sure that you set the
remote directory to a different one, one that may not
contain any files that could lead to some sort of crash. So
you can just go to File->Connect to FTP Server... and then
make sure the "Use Default Directories" isn't selected and
start from somewhere else that way. Or you could just put
the files that might be causing this elsewhere. I'm quite
convinced that it's just a few files that are causing this,
and I'm actually going to see if I can look through the code
in the Java FTP Server that's being used here.
Logged In: YES
I tested the server, too, and the only thing to mention is
that permissions are not working correctly yet - I was able
to browse directories and transfer files, though. Please
reconfirm this bug, maybe it's gone after some sorting
changes/bugfixes I made when implementing directory sorting
Strange thing: After restarting my own ftp server I
experienced exactly this problem, which was caused by the
date style changed from "Aug 30"-style to
"2004-11-18"-style. That confused the parser and I had to
improve it once again... Hopefully things work with this
server correctly now, too... :)
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.