Skip to content
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

Implement preserve #81

Merged
merged 10 commits into from
May 26, 2024
Merged

Conversation

datadius
Copy link
Contributor

protocol.go had a bug. Checking if the buffer had more information was not implemented correctly, but it wasn't affecting current functionality. Now that -p is added, I could see the bug. I replaced the check for io.eof with a check if there is any data left buffered.

I added in the configurer the option to have the preserve field set to true through the Preserve method.

To update the signature with a return value, I create a new method linked to client. If there is an error and the user tries to use the FileInfos object, then they will get a null pointer. I think that makes it more obvious that they didn't check the error.

I also added a test for the -p functionality, but I think I might need more to cover it better. I'm not sure exactly how to test that the FileInfo has the right time in atime and mtime, as the file is create in the docker container by cloning the repo, so I don't know if the file information is preserved.

I'm open to suggestions and comments 😄.

I think the tests are lacking and I plan to write more before we merge.

Copy link
Owner

@bramvdbogaerde bramvdbogaerde left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Impressive what you have achieved in such a short period of time. It is a rather large proposal, but I agree with most of it. I left comments in locations where I had some concerns or questions. Thanks again!

client.go Outdated Show resolved Hide resolved
client.go Outdated Show resolved Hide resolved
configurer.go Outdated Show resolved Hide resolved
configurer.go Outdated Show resolved Hide resolved
tests/basic_test.go Outdated Show resolved Hide resolved
@@ -68,20 +68,16 @@ func ParseResponse(reader io.Reader, writer io.Writer) (*FileInfos, error) {
return nil, err
}

message, err = bufferedReader.ReadString('\n')
if err == io.EOF {
if bufferedReader.Buffered() == 0 {
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am a bit lost here what this is supposed to mean. Buffered returns the number of bytes remaining in the read buffer, but as far as I see the buffer should already be empty since we read all its information for parsing the time message. We do not make any Acks in between so we do not expect another message back from the remote. My suggestion is to add more comments to this function to make it more clear why certain checks are necessary and what part of the protocol we are considering at each line in the code.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

https://github.com/charmbracelet/wish/blob/e6e9fc4c8a253cf263334efa95d31e7af7034970/scp/scp.go#L128

wish is a popular ssh custom server. Their implementation allows for sending out the time and permissions in the same message. There is an argument that it's not following the protocol, but being so popular, I thought it would be nice to accommodate and take into consideration the instances in which someone could make a custom ssh implementation.

If you believe we shouldn't accommodate that kind of custom implementation, then I will remove that piece of logic to keep it clean.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see, I think you make a good argument for keeping it, but make sure that it does not interfere with implementations that do follow the protocol.

protocol.go Outdated Show resolved Hide resolved
tests/basic_test.go Outdated Show resolved Hide resolved
client.go Outdated Show resolved Hide resolved
client.go Show resolved Hide resolved
@datadius
Copy link
Contributor Author

datadius commented May 1, 2024

Figured out the paths within the Docker and now I'm checking against the file that we're reading. Now the test is more relevant to testing that the feature works.

@bramvdbogaerde
Copy link
Owner

I see you already made some changes, are those ready for review? If not, could you notify me when they are. Thanks!

Kind regards,

Bram

@datadius
Copy link
Contributor Author

datadius commented May 1, 2024

I see you already made some changes, are those ready for review? If not, could you notify me when they are. Thanks!

Kind regards,

Bram

They are ready to review. I think this is close to final form in my opinion. Only thing I would add is perhaps some more testing, but I haven't thought of any new ones.

@bramvdbogaerde bramvdbogaerde self-requested a review May 2, 2024 07:46
Copy link
Owner

@bramvdbogaerde bramvdbogaerde left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added some minor comments, I think the PR is ready for merging after those are addressed.

client.go Show resolved Hide resolved
@@ -68,20 +68,16 @@ func ParseResponse(reader io.Reader, writer io.Writer) (*FileInfos, error) {
return nil, err
}

message, err = bufferedReader.ReadString('\n')
if err == io.EOF {
if bufferedReader.Buffered() == 0 {
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see, I think you make a good argument for keeping it, but make sure that it does not interfere with implementations that do follow the protocol.

tests/basic_test.go Show resolved Hide resolved
@datadius
Copy link
Contributor Author

datadius commented May 2, 2024

This is all I have for now. Next I plan to look into implementing the directory functionality, but I will be off for 2 weeks starting next week

@datadius
Copy link
Contributor Author

datadius commented May 4, 2024

we should be able to also close this one #63

@datadius datadius requested a review from bramvdbogaerde May 16, 2024 12:44
@datadius
Copy link
Contributor Author

@bramvdbogaerde when do you plan to merge this pull request?

@bramvdbogaerde bramvdbogaerde merged commit e40dcd9 into bramvdbogaerde:master May 26, 2024
1 check passed
@bramvdbogaerde
Copy link
Owner

Merged! Thanks a lot.

Note: I squashed your commits into a single one to keep commit history clean in the master branch.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants