[net] Non existant files and empty directories not detected

• Key: NET-78
• Type: Bug
• Status: Closed
• Resolution: Fixed
• Priority: Major
• Assignee: Unassigned
• Reporter: jill
• Affects Version/s: 1.1

Environment

Operating System: All
Platform: All

Description

When using the method FTPClient.listFiles(pathname) on a non-existant file or an
empty directory, incorrect results are returned - in both cases a null array
would be expected.

In the case of a non-existant file an array of size 1 is returned with the value
being "... No such file or directory ...".

In the case of an empty directory an array of size 0 is returned.

Comments

[Steve Cohen]

Please, can you indicate on what kind of server (UNIX, NT, OS/2, etc.) is this
behavior found?

[jill]

The behaviour was observed while running the FTP client software on Redhat 7.2
but connecting to an FTP server on Sun Solaris 8 (Sparc).

[Steve Cohen]

reopen after 1.2.2 release

[Steve Cohen]

I am not sure why "in both cases a null array would be expected." I see nothing
in the documentation that would lead one to expect that result. In the case of
an empty directory, it seems to me that an empty array is unquestionably the
correct result. The case of a nonexistent file seems a bit more arguable, but I
still think that a case can be made for an empty array. In any case, those are
the results I get now. I don't get "No such file or directory" and a look
through the code, which has changed since this bug was written, shows that such
non-parseable input will now be discarded.

I am changing the status of this bug, changing it to WONTFIX, although, as
explained above, I don't really believe that returning a 0-length array is a bug
in either case you mention.

[Steve Cohen]

On second thought, since the valid part of your bug has now been fixed, I am
changing the status to FIXED.