Changing upload direcory (not sure is an issue)... about tusd

[kvz]

Hey there, the solution is simpler than what you're currently trying, if you run the binary, tusd -help, you'll see that you can configure the data dir via the -dir= uploadDirectory command-line argument. Does that help?

[Acconut]

@kvz What you are proposing is a better solution to

Then I have stopped the tusd application and I have changed the upload directory from "data" to "uploadDirectory" in main.go.

but this does not fix his main problem:

But when I try to upload one file that I have already uploaded in the previous tusd session (with upload dir="data") I have receiveed an "unexpected status code (404) while resuming upload".

This is actually not a bug in tusd but a wired behaviour in tus-java-client which is used internally by tus-android-client. So following happens:

• tusd is started and stores the uploads in data
• tus-android-client creates a new upload, caches the upload's URL (for later resuming) and uploads the file successfully
• tusd is restarted with uploadDirectory
• tus-android-client sees that you are trying to upload the same file again and attempts an resume
• tusd is not able to find the upload (which android wants to resume), since you have changed the directory in which the files are stored, and therefore sends the 404 (Not Found) status code back to android

That's where your error comes from. The expected behavior of tus-android-client should be that after resuming failed it falls back to creating a new upload. However, this has not been implemented yet (I overlooked this case) but should be a simply fix. I will try to get this done quickly. Thank you for reporting this inconsistency :)

[masail]

Thank you for your replies! :)
I think I'm running the "source" version (but, you know, I'm newbe on Go!;) I cloned the project following instruction in README.md

Acconut, if I have understand your reply, this behavior is related to the way tus-android-client keeps track of the upload already done or, at least, started. Is something done with something like a SharedPreferences? Tomorrow I'll look into tus-android-client to try to understand something more.

I was looking for a way to implementing resumable ulpoad from a while and when I finally found your project I could not believe on my eyes!
Great job guys!!

Thanks a lot!

[Acconut]

@masail I just want to let you know that I will work on this issue this week, so you can expect a fix by the end of it. However, there are still some open questions but we will figure it out :)

Acconut, if I have understand your reply, this behavior is related to the way tus-android-client keeps track of the upload already done or, at least, started. Is something done with something like a SharedPreferences

That's correct.

I was looking for a way to implementing resumable ulpoad from a while and when I finally found your project I could not believe on my eyes!
Great job guys!!

It's always a pleasure for us to hear such great feedback :)

[masail]

Thank you for yours work! :)

Excuse me, but I would ask for another question, related to the means of the content of the ".info" file: can I write here or I have to create another thread?

Thanks.

[Acconut]

Excuse me, but I would ask for another question, related to the means of the content of the ".info" file: can I write here or I have to create another thread?

No need to excuse. :) To be honest, I do not really mind but in general it's better to separate different discussion topics to make it easier to follow the conversation. So I would be pleased if you could create a new issue in this repository.

[Acconut]

@masail Just to give you a quick update on this topic. The reason why I haven't pushed a fix out yet is that it is really hard for the client to tell when it should stop trying to resume an upload and just start a new one. In your case it should immediately do so after receiving the 404 Not Found status code. However, in the real world there are some situations where this behavior is undesired. Imagine a badly code deploy or a proxy failure causing the tus server to return 4xxs to the client and everyone starts their uploads from scratch.

Google has some great guidelines for handling these cases (https://developers.google.com/drive/v3/web/manage-uploads#best-practices) and I guess they are also a good go for tus. However, I would enjoy some feedback from @kvz :)

[kvz]

I'm having trouble following this conversation. What is the problem we're trying to address? Establishing when a client should give up retrying per some default?

[Acconut]

Establishing when a client should give up retrying per some default?

Yes, in which cases the HTTP request should be retried or the entire attempt to resume the upload should be stopped and instead a new upload should be started. The guidelines by Google make some great points in this regard.

[kvz]

I think their best practices make sense. If there's a naughty proxy in between throwing a 404, then i think it's just tough luck. I would not cripple the 99.99% of other use cases just to have resumability in this edge case. Would you agree?

[Acconut]

I have already been working on this. Some progress can be seen here: tus/tus-java-client@b3db9b3

[Acconut]

The 0.3.0 release of the tus-java-client includes the new TusExecutor class which provides an easy way for implementing retries. Please consult the libraries' README for more information (https://github.com/tus/tus-java-client#usage).