Date Parsing Problem when Unix format on Windows

Question

We have a case where we are connecting to a Windows machine, but the directory listing comes back in a Unix format. This is causing date parsing problems. See attached stacktrace:


java.text.ParseException: Unparseable date: "-rwxrwxrwx 1"
at java.text.DateFormat.parse(DateFormat.java:344)
at com.enterprisedt.net.ftp.WindowsFileParser.parse(WindowsFileParser.java:98 )
at com.enterprisedt.net.ftp.FTPFileFactory.parse(FTPFileFactory.java:118 )
at com.enterprisedt.net.ftp.FTPClient.dirDetails(FTPClient.java:1557)

This seems to be caused by the library examining the system information, determining that it is a Windows machine, and then using the WindowsFileParser. Here is what it looks like when I connect to the machine with a command line FTP:


H:\>ftp XXXX
Connected to XXXX.
220 XXXX Microsoft FTP Service (Version 5.0).
User (XXXX:(none)): ME
331 Password required for ME.
Password:
230 User ME logged in.
ftp> dir
200 PORT command successful.
150 Opening ASCII mode data connection for /bin/ls.
-rwxrwxrwx 1 owner group 75776 Jun 28 11:43 U040628141072GCDR.data
226 Transfer complete.
ftp: 609 bytes received in 0.01Seconds 60.90Kbytes/sec.


Is there any way to override the selection of the FileParser to explicitly choose UnixFileParser over WindowsFileParser?

Thanks.

Answer 1

Weird - why is the MS FTP server returning Unix format dirs?

Just to confirm, can you log in on the command line and type

quote SYST

If it returns Windows_NT that is why the Windows parser is being used. It seems that SYST is not as reliable as we'd hoped for determining the dir listing format.

There is not currently a way to force use of the UnixFileParser, although this sounds like a useful feature. We will also reconsider use of SYST and perhaps try to detect the listing format another way.

If you want things to work right now, the best thing is to edit FTPFileFactory.java and in the constructor, replace

setParser(system);

with

parser = new UnixFileParser();

This will force use of the unix parser in all cases - please let us know if this works for this particular FTP server.

We have a case where we are connecting to a Windows machine, but the directory listing comes back in a Unix format. This is causing date parsing problems.
.....

Is there any way to override the selection of the FileParser to explicitly choose UnixFileParser over WindowsFileParser?

Thanks.

Answer 2

Here is the SYST output:

H:\>ftp XXX
Connected to XXX.
220 XXXMicrosoft FTP Service (Version 5.0).
User (XXX:(none)): ME
331 Password required for ME.
Password:
230 User ME logged in.
ftp> quote SYST
215 Windows_NT version 5.0
ftp> dir
200 PORT command successful.
150 Opening ASCII mode data connection for /bin/ls.
drwxrwxrwx 1 owner group 0 Jun 22 17:29 filev
drwxrwxrwx 1 owner group 0 Jun 29 7:55 filew
drwxrwxrwx 1 owner group 0 Jun 29 7:25 filex
drwxrwxrwx 1 owner group 0 Jun 22 17:29 filey
drwxrwxrwx 1 owner group 0 Jun 28 21:55 filez
226 Transfer complete.
ftp: 330 bytes received in 0.02Seconds 16.50Kbytes/sec.

We are checking to see if the FTP server is configured in some interesting way. (Unfortunately, we do not own this machine and cannot make configuration changes.) We will hardcode the parser and will let you know what happens.

Answer 3

Apparently, the Windows FTP server is configured to give Unix directory outputs (we are mostly a Unix shop, so most of our scripts expect Unix-type output.)

I don't have access to the machine, but here is a web site that includes a dialog box showing how to configure it to emulate Unix directory listings (tip #4 doesn't address this, but does show the dialog where the configuration would happen).

http://www.windowsecurity.com/articles/ ... erver.html

Rather than always hardcoding the parser in the factory, we are considering changing it to look not only at the SYST output, but in the case of Windows, also do a directory listing. The message we get back with the listing is:

150 Opening ASCII mode data connection for /bin/ls.

We are planning on keying off the "/bin/ls" in the reply string to recognize the Windows configured as Unix case. Don't know how it would work on a regularly configured Windows machine, but no worse then always hardcoding it as Unix.

Answer 4

We are planning to modify edtFTPj to 1) use SYST (as we do now) and 2) to switch to Unix if the first raw string in the listing looks like a Unix listing (i.e. it doesn't begin with a digit but rather a permissions string).

Will that work for you?

Apparently, the Windows FTP server is configured to give Unix directory outputs (we are mostly a Unix shop, so most of our scripts expect Unix-type output.)

I don't have access to the machine, but here is a web site that includes a dialog box showing how to configure it to emulate Unix directory listings (tip #4 doesn't address this, but does show the dialog where the configuration would happen).

http://www.windowsecurity.com/articles/ ... erver.html

Rather than always hardcoding the parser in the factory, we are considering changing it to look not only at the SYST output, but in the case of Windows, also do a directory listing. The message we get back with the listing is:

150 Opening ASCII mode data connection for /bin/ls.

We are planning on keying off the "/bin/ls" in the reply string to recognize the Windows configured as Unix case. Don't know how it would work on a regularly configured Windows machine, but no worse then always hardcoding it as Unix.

Answer 5

That will work great for us.

Answer 6

We have a preliminary build of 1.4.2 that you can test out if you wish - send an email to support at enterprisedt dot com and ask for 1.4.2 beta, and we'll send you the jar file. Please report back.

That will work great for us.

Answer 7

1.4.2 is now released and has a fix for this bug.