[
https://issues.apache.org/jira/browse/NET-376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13007914#comment-13007914
]
Colin Stone commented on NET-376:
---------------------------------
Thanks for the response.
The code has been implemented as follows:
FTPListParseEngine parseEngine = anFTPClient.initiateListParsing(parserType,
arguments);
where parserType is UnixFTPEntryParser.
When I look into the results contained within the parse engine (with no
setHidden..) it looks like the output from a ls -l:
drwxr-xr-x 2 MYUSER1 TSOUSER 608 Mar 16 18:25 test1
By changing the arguments to -al I get
drwx------ 3 MYUSER1 TSOUSER 320 Mar 16 18:25 .
dr-xr-xr-x 14667 NETVIEW TTY 0 Mar 17 13:53 ..
drwxr-xr-x 2 MYUSER1 TSOUSER 608 Mar 16 18:25 test1
which is exactly what I wanted.
However when I run the code with no arguments but the setListHiddenFiles set to
true on the FTPClient, I get no files returned and the parse engine seems to
have entries corresponding to:
ftp> ls -a
200 Port request OK.
125 List started OK
.
..
test1
And the parse engine does not interpret them.
As you can see I have already applied a workaround that is acceptable for our
requirements, simply by passing the arguments. It is possible that we have an
unusual server FTP setup which may be missing something configuration wise, so
we may just have an extreme edge condition but worth logging I thought. Sorry I
can't help on the publically available front.
> 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