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

Bogus first status callback #88

Closed
dkocher opened this issue Apr 8, 2015 · 6 comments
Closed

Bogus first status callback #88

dkocher opened this issue Apr 8, 2015 · 6 comments
Assignees

Comments

@dkocher
Copy link
Contributor

dkocher commented Apr 8, 2015

The first callback on TransferStatusCallbackListener#statusCallback has set bytesTransfered set to the total length even when totalFilesTransferredSoFar is still 0.

@dkocher
Copy link
Contributor Author

dkocher commented Apr 23, 2015

This issue is not resolved in 4.0.2.1-RELEASE.

@michael-conway
Copy link
Collaborator

Hey david I fixed a place I found on the put...can you narrow down the type
of callback this was an issue then?

On Thu, Apr 23, 2015 at 4:05 PM, David Kocher [email protected]
wrote:

This issue is not resolved in 4.0.2.1-RELEASE.


Reply to this email directly or view it on GitHub
#88 (comment).

@dkocher
Copy link
Contributor Author

dkocher commented Apr 23, 2015

I see. Looks like it is fixed for PUT but still bogus for GET. (From DataTransferOperations#getOperation)

@michael-conway
Copy link
Collaborator

OK we'll push out a little dot release after we nail down all of the
cyberduck stuff and add that.

I want to focus on getting the performance up to snuff first.

Cheers!
MC

On 4/23/15 4:29 PM, David Kocher wrote:

I see. Looks like it is fixed for PUT but still bogus for GET. (From
|DataTransferOperations#getOperation|)


Reply to this email directly or view it on GitHub
#88 (comment).

@dkocher
Copy link
Contributor Author

dkocher commented Apr 24, 2015

I suppose this is now fixed with f786632.

@michael-conway
Copy link
Collaborator

Yes think so but of course events overtook this afternoon. Will sew that
up and push to maven soon
On Apr 24, 2015 4:50 PM, "David Kocher" [email protected] wrote:

I suppose this is now fixed with f786632
f786632
.


Reply to this email directly or view it on GitHub
#88 (comment).

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

No branches or pull requests

2 participants