[jira] [Updated] (NET-577) Fails to parse FEAT response from Gene6 FTP server
[
https://issues.apache.org/jira/browse/NET-577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jochen Kemnade updated NET-577:
---
Summary: Fails to parse FEAT response from Gene6 FTP server (was: Fails to
parse FEAT response from Microsoft FTP Service)
Fails to parse FEAT response from Gene6 FTP server
--
Key: NET-577
URL: https://issues.apache.org/jira/browse/NET-577
Project: Commons Net
Issue Type: Bug
Components: FTP
Affects Versions: 3.3
Reporter: Jochen Kemnade
This is probably rather a bug in the server implementation, but anyway.
The response from a Microsoft FTP Service I'm trying to work with looks like
that:
{noformat}
211-FEAT
SIZE
MDTM
211 END
{noformat}
So, after parsing the response, the entries in the features map are {{
SIZE}} and {{ MDTM}}.
While it doesn't adhere to the RFC (there's supposed to be a single leading
space for each feature), it should be possible to work around that kind of
broken response.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (NET-577) Fails to parse FEAT response from Gene6 FTP server
[
https://issues.apache.org/jira/browse/NET-577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14620284#comment-14620284
]
Jochen Kemnade commented on NET-577:
It's a Gene6 FTP server 3.9.0 (Build 2) (www.g6ftpserver.com). I haven't
checked whether the current version also behaves like that. And yes, the
behavior is wrong according to the RFC.
Fails to parse FEAT response from Gene6 FTP server
--
Key: NET-577
URL: https://issues.apache.org/jira/browse/NET-577
Project: Commons Net
Issue Type: Bug
Components: FTP
Affects Versions: 3.3
Reporter: Jochen Kemnade
This is probably rather a bug in the server implementation, but anyway.
The response from a Microsoft FTP Service I'm trying to work with looks like
that:
{noformat}
211-FEAT
SIZE
MDTM
211 END
{noformat}
So, after parsing the response, the entries in the features map are {{
SIZE}} and {{ MDTM}}.
While it doesn't adhere to the RFC (there's supposed to be a single leading
space for each feature), it should be possible to work around that kind of
broken response.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (NET-558) getModificationTime(filename) returns complete received line including response code
[ https://issues.apache.org/jira/browse/NET-558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14618247#comment-14618247 ] Jochen Kemnade commented on NET-558: I also get a trailing newline in 3.4-SNAPSHOT. getModificationTime(filename) returns complete received line including response code -- Key: NET-558 URL: https://issues.apache.org/jira/browse/NET-558 Project: Commons Net Issue Type: Bug Components: FTP Affects Versions: 3.3 Environment: The ftp server supports MDTM. Reporter: Ralph Becker Priority: Minor Labels: commons-net, ftp Fix For: 3.4 When retrieving the last modification time of a file on the server via the method getModificationTime(String filename) it returns something like 213 2014112706 where only the part after the space is the relevant data. I digged deeper and i found that the first part before the space is the positive response code which is not removed before getModificationTime returns. I consider this a minor bug as i think there is a simple work around (split by space, use second part only) but i do not believe that the result of the method is what a user expects regarding the documentation of that method. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (NET-577) Fails to parse FEAT response from Microsoft FTP Service
Jochen Kemnade created NET-577:
--
Summary: Fails to parse FEAT response from Microsoft FTP Service
Key: NET-577
URL: https://issues.apache.org/jira/browse/NET-577
Project: Commons Net
Issue Type: Bug
Components: FTP
Affects Versions: 3.3
Reporter: Jochen Kemnade
This is probably rather a bug in the server implementation, but anyway.
The response from a Microsoft FTP Service I'm trying to work with looks like
that:
{noformat}
211-FEAT
SIZE
MDTM
211 END
{noformat}
So, after parsing the response, the entries in the features map are {{ SIZE}}
and {{ MDTM}}.
While it doesn't adhere to the RFC (there's supposed to be a single leading
space for each feature), it should be possible to work around that kind of
broken response.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (NET-558) getModificationTime(filename) returns complete received line including response code
[ https://issues.apache.org/jira/browse/NET-558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14608099#comment-14608099 ] Jochen Kemnade commented on NET-558: If I use the `substring(4)` approach in 3.3 with a WINDOWS ftp server, there's still a trailing newline in the response. Not sure if that'll be an issue in 3.4. getModificationTime(filename) returns complete received line including response code -- Key: NET-558 URL: https://issues.apache.org/jira/browse/NET-558 Project: Commons Net Issue Type: Bug Components: FTP Affects Versions: 3.3 Environment: The ftp server supports MDTM. Reporter: Ralph Becker Priority: Minor Labels: commons-net, ftp Fix For: 3.4 When retrieving the last modification time of a file on the server via the method getModificationTime(String filename) it returns something like 213 2014112706 where only the part after the space is the relevant data. I digged deeper and i found that the first part before the space is the positive response code which is not removed before getModificationTime returns. I consider this a minor bug as i think there is a simple work around (split by space, use second part only) but i do not believe that the result of the method is what a user expects regarding the documentation of that method. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (NET-558) getModificationTime(filename) returns complete received line including response code
[
https://issues.apache.org/jira/browse/NET-558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14608099#comment-14608099
]
Jochen Kemnade edited comment on NET-558 at 6/30/15 10:40 AM:
--
If I use the {{substring(4)}} approach in 3.3 with a WINDOWS ftp server,
there's still a trailing newline in the response. Not sure if that'll be an
issue in 3.4.
was (Author: jkemnade):
If I use the `substring(4)` approach in 3.3 with a WINDOWS ftp server, there's
still a trailing newline in the response. Not sure if that'll be an issue in
3.4.
getModificationTime(filename) returns complete received line including
response code
--
Key: NET-558
URL: https://issues.apache.org/jira/browse/NET-558
Project: Commons Net
Issue Type: Bug
Components: FTP
Affects Versions: 3.3
Environment: The ftp server supports MDTM.
Reporter: Ralph Becker
Priority: Minor
Labels: commons-net, ftp
Fix For: 3.4
When retrieving the last modification time of a file on the server via the
method getModificationTime(String filename) it returns something like
213 2014112706 where only the part after the space is the relevant data.
I digged deeper and i found that the first part before the space is the
positive
response code which is not removed before getModificationTime returns.
I consider this a minor bug as i think there is a simple work around
(split by space, use second part only) but i do not believe that
the result of the method is what a user expects regarding the documentation
of that method.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
