|
Antoine,
commons-net.jar + jakarta-oro.jar in use are those supplied as part of ant O/S of FTP client is MS Windows 2000 v 5.00.2195 SP 2 uname -v returns 4 Language installed is English (United Kingdom) Command line ftp client listing: ZMIR69.m commons-net and jakarta-oro are not bundled with ant.
You need both of them to execute the FTP task. ant-commons-net and ant-jakarta-oro are two jar files containing tasks dependent upon commons-net and jakarta-oro respectively, but they are not jakarta-oro and commons-net. So again, which version of commons-net and jakarta-oro are you using ? Also do a directory listing with ls -l through the ftp client and send us the output (I think ls -l somefile.txt redirects the output directly into a file called somefile.txt, ===> then you can attach somefile.txt to this bug report. Created an attachment (id=10703)
ls-l performed from the ftp client as requested Antoine,
I am using the following: commons-net-1.1.0.jar and jakarta-oro-2.0.8.jar I've also sent you an attachment, as requested, which is an 'ls-l' from the ftp Mark Antoine is basically correct. There is (currently) no support for this ftp format in commons.net.
The format is CLOSE TO but not identical to the Standard unix ftp server list format that is the default in commons-net. Here is a typical unix ftp standard listing followed by one of yours: Clearly, the problem seems to be one of locale (reversal of the month and day fields). The The basic problem is that the FTP specification (RFC959) defines the FTP listing format in a I have never heard this complaint about unix servers in non-American locales, but I have heard Additionally, commons-net is moving toward an autodetection scheme for ftp server types. It It's a real mess, frankly, due to the vagueness of the ftp spec on this matter. As a committer However, it's totally out of Ant's hands to be able to fix this. bug report reassigned to commons-dev
No problem. I'd be happy to assist with any future work you may need to do on
commons-net (work-schedules permitting!). If you do go ahead, let me know what additional information you need. Mark To start with I could use some data.
As you appear to be in the UK, are you in a position to do a little experimenting, contacting That would be most helpful. I need to know two things. If, as I suspect the answer to both of these, but especially #2, is negative, then the only way The only servers we have here are AIX so I cannot confirm whether the problem
exists with other server types. We did change the locale within the Unix shell and can confirm that the output With LANG=en_US
With LANG=en_UK
An "ls -l" within FTP remains resolutely the same whether Similarly, I don't think there is a way of determining the locale of the FTP Created an attachment (id=12848)
AIXFTPEntryParser.java Created an attachment (id=12849)
AIXFTPEntryParserTest.java I agree with Steve that there may be a more elegant long-term solution to this,
however, in the interests of the interim, I have created an AIX parser and testcase that successfully parses the output that Mark sent previously. Steve et. al, let me know if you approve of this approach, and I can commit it. Sorry, my bad. I didn't realize that Daniel has an AIX parser in there already.
Rory - I favor your submission far above the old thing in the proposal tree which I think must
be what you're talking about. Your submission will work with the current setup and the old one needs significant rework. However, before we commit it, I would like to get clarity on my main question, which nobody Is the d/m/y ordering of the date a particular attribute of AIX or the AIX ftp server, anywhere Because if it's the former, I am opposed to creating an AIX parser that is only good for a In other words, I am opposed to saying "AIX" when what we really mean is "AIX in a British Also, we need to now think about the autodetection mechanism. Do you know how AIX FTP This is what i got on an AIX 4.2:
UNIX Type: L8 Version: BSD-44 Not much information to gather a locale. I agree with Steve - we need a generic problem to deal with the date formatting
issues that occur. I think finding an elegant solution is very, very difficult. A lot of FTP servers can not be reliably identified (I've tried a few AIX servers this morning, from which they returned nothing useful or consistent from SYST), and the date format can vary wildly based on server configuration. Witness the IIS FTP server options: and http://www.microsoft.com/windows2000/en/server/iis/htm/asp/apro1k9x.htm Two possibilities spring to mind: 1. We could match an entry from an initial 'ls' against a couple of regexes 2. We could explicitly add a setDateFormat() to the FTPClient class, and allow a Rory:
Your report on AIX's SYST command response confims my suspicion that this is just a flavor of the UnixFTPFileEntryParser. The date formatting is another issue entirely As for solutions to THAT problem, of the two that you present, I much prefer #2. It's realistic It's pretty obvious to me that we should not expect to find any automated solution using SYST So let's look at what we'd need to do to define a date format. It's going to be more complicated I think we need a bit of upfront design and then we'll be ready to work on a solution. So let's The mechanisms to fix this are in the trunk and will be released in 1.4. I have
added a TestCase to the repository that shows how you can solve this issue using the FTPClientConfig class. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Closed
Major
[net] FTP "get" and "list" tasks fail
attachment to this bug report.
I do not think that the ftp task corrupts the name of the files. There is
probably not the right parser in commons-net for the type of listings produced
by your AIX ftp server (langage ?)
Cheers,
Antoine