-
Notifications
You must be signed in to change notification settings - Fork 97
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add ListParser as a config option #38
base: master
Are you sure you want to change the base?
Conversation
@@ -149,6 +150,12 @@ type Config struct { | |||
// hung connections. | |||
DisableEPSV bool | |||
|
|||
// Provide a custom parser for the outcome of the LIST command | |||
// If this is not set, a default LIST parser is used that will handle most outcomes | |||
ListParser interface { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can this just be a function instead of an interface?
@@ -139,6 +139,9 @@ func (c *Client) ReadDir(path string) ([]os.FileInfo, error) { | |||
return nil, err | |||
} | |||
parser = func(entry string, skipSelfParent bool) (os.FileInfo, error) { | |||
if c.config.ListParser != nil { | |||
return c.config.ListParser.ParseLIST(entry) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about the skipSelfParent
flag? (I think its purpose is to exclude "." and ".." when listing.) Perhaps instead of passing that flag into the parser, we could exclude "." and ".." here using the return value?
@@ -149,6 +150,12 @@ type Config struct { | |||
// hung connections. | |||
DisableEPSV bool | |||
|
|||
// Provide a custom parser for the outcome of the LIST command | |||
// If this is not set, a default LIST parser is used that will handle most outcomes | |||
ListParser interface { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you add tests for the new functionality?
I've encountered some cases where the default parseLIST function fails to parse the outcome of a LIST command, despite getting useful data. This was encountered while communicating with an older FTP server.
Rather than attempting to cover all the types of output an FTP server could give in response to a LIST command, I've added the ability to specify a custom ListParser to handle these cases.
Here's a sample format i've seen that could not be handled, with fake fields:
OWNER 777 11/12/13 01:02:03 TYPE /some/directory/file.txt