[net] Unix parser does not handle special files.

• Key: NET-25
• Type: Bug
• Status: Closed
• Resolution: Fixed
• Priority: Major
• Assignee: Unassigned
• Reporter: Neil Clayton
• Affects Version/s: 1.2

Environment

Operating System: other
Platform: Other

Description

At present, the Unix parser (v 1.2.1 of commons-net) doesn't match against a
file with a leading 's'.

A side effect is that the parser returns null back to engine.getFiles() (because
the listed line from the FTP server doesn't match the regex), which is then
added to the temp LinkedList being created.

The result is, you end up with null FTPFile instances in the collection returned
by listFiles().

I'm not sure if this is by design or not.

Comments

[Mario Ivankovits]

Hmmm. The Unix parser should correctly handle those files.

Is this a public ftp where we can test this, or could you please provide a ftp
listing and the output of the "syst" command.

On an windows machine you could the command-line utility "ftp".
e.g.
ftp your.host
(login)
quote syst
dir

[Neil Clayton]

I found it by scanning against /dev.

e.g:

ftp> open localhost
Connected to samson.
220 ProFTPD 1.2.9 Server (Samson) [samson.cloudnine.net.nz]
Name (localhost:neil): neil
331 Password required for neil.
Password:
230 User neil logged in.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> ls /dev/gpmctl
200 PORT command successful
150 Opening ASCII mode data connection for file list
srwxrwxrwx 1 root root 0 Jun 19 08:30 /dev/gpmctl
226 Transfer complete.
ftp> syst
215 UNIX Type: L8

[Neil Clayton]

If "([bcdlf-])" is changed to "([sbcdlf-])" (additional S), then the regex then
matches the line.

[Steve Cohen]

Well, we can certainly do that. However, maybe we ought to take care of all the
cases:

Here is what man ls (as interpreted by
http://www.mcsr.olemiss.edu/cgi-bin/man-cgi?ls+1 - this just happened to be the
first such entry google found for me, how authoritative is it? ) says:

The mode printed under the -l option consists of eleven possible
characters. (note sc, I only count 9). The first character may be one of
the following:

d if the entry is a directory;
l if the entry is a symbolic link;
b if the entry is a block special file;
c if the entry is a character special file;
s if the entry is a XENIX semaphore;
m if the entry is a XENIX shared data (memory);
p if the entry is a fifo (named pipe) special file;
S if the entry is an AF_UNIX address family socket;

• if the entry is a regular file.

So solving all of these would entail a regex of [sbcdlf-mpS].

Before committing such a change, though, I would like to ask, is this list
authoritative, and if so, SHOULD ftp be returning XENIX semaphores (whatever
they are), XENIX shared data, AF_UNIX address family sockets, fifo special
files, etc. Also, are these meanings common to all systems or do the letters
have different meanings on different systems?

Any thoughts?

[Neil Clayton]

Thoughts? Yep!
1) Don't know if it's authoratitve. I guess it depends on the ls doc you're
looking at. My man ls doesn't include any docs on the specifics at all, and
neither does an info ls (debian).

2) I would think that it is going to be up to the platform and FTP server
implemenation as to whether or not it can return meaningful data for those
particular special files.

Having said that, I don't think that they should be excluded from parsing. I
wouldn't mind if the FTP server threw a wobly (or even an IOException) upon me
attempting to read the content - but I would like to at least see the content in
a listing. Assuming it's implemented, it would also make sense to have FTPFile
return the type as being UNKNOWN_TYPE for these other cases.

So my vote would be to add the parsing, and let the behavior be determined by
the server implementation.

[Steve Cohen]

fixed in accordance with above suggestions. Type of s, S, m, and p now supported. All are
indentified as being of UNKNOWN_TYPE but they will parse.