Mailing-List: contact issues-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: issues@commons.apache.org
Date: Thu, 17 Mar 2011 15:24:29 +0000 (UTC)
From: "Colin Stone (JIRA)" <jira@apache.org>
To: issues@commons.apache.org
Message-ID: 
 <710628488.8949.1300375469521.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <1982421802.8637.1300359689757.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] Commented: (NET-376) setListHiddenFiles doesn't work for HFS
 file system running under zos
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/NET-376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13007953#comment-13007953 ] 

Colin Stone commented on NET-376:
---------------------------------

As you would expect really. 
LIST 
125 List started OK
250 List completed successfully.
when set to false
LIST -a 
125 List started OK
250 List completed successfully.
when set to true

The issue is in the format or the returned rows and how the parser reads them. In the first LIST presents the data in the way I would expect LIST -l to do (even though the -l parameter is not present) and the parser sees all of the detail including user, group, permissions etc. The LIST -a simply presents the file name and the UnixFTPEntryParser rejects each entry as they doesn't match on the regexps.


> setListHiddenFiles doesn't work for HFS file system running under zos
> ---------------------------------------------------------------------
>
>                 Key: NET-376
>                 URL: https://issues.apache.org/jira/browse/NET-376
>             Project: Commons Net
>          Issue Type: Bug
>          Components: FTP
>    Affects Versions: 2.2
>         Environment: IBM z/OS running HFS
>            Reporter: Colin Stone
>
> The implementation for setListHiddenFiles is essentially the use of a '-a' parameter appended to the LIST command. This retrieves the data in a different format to without the parameter and the parse engine used by initiateListParsing fails to read the lines returned. 
> I suggest the parameter should have been '-al' for this scenario

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira