About the file name about tusd

[Acconut]

The reason why the tusd server generates random IDs for uploads instead of using the file's name is that the protocol (see http://tus.io) does not force the client to tell the server the file name. This is a decision that has been made on purpose. However, we do understand that such information is sometimes crucial and therefore you are able to use the mechanics of meta data to pass it along. In this case the file name will be presented as meta data inside the .info object.

To add the file name using our Android/Java client, you have to use the TusUpload#setMetadata method and pass it a map containing the information. Right now, this is not automatically done but I will enable to by default ASAP.

[Acconut]

Right now, this is not automatically done but I will enable to by default ASAP.

The code for this change is already in the Android and Java repositories and will be released very soon.

[hanjun-lin]

Thanks a lot. Latest commits of client sides are work now.

By the way, although current sample code can solve the problem of original uploaded file name by fetching from the .info file. But the performance and efficiency is not good for production because of the file I/O operating for reading the .info file.

It will be good if the file extension name stored in the server is same as uploaded file. (e.g. uploaded file extension name is .png and server stored file extension name is .png [currently is .bin])

[Acconut]

But the performance and efficiency is not good for production because of the file I/O operating for reading the .info file.

Please explain this thought more. You need a place to save the additional information about the upload and this is exactly why we need it. We cannot simply remove it. Also, if you have bigger uploads, the impact of reading this small file is negligible IMO.

It will be good if the file extension name stored in the server is same as uploaded file. (e.g. uploaded file extension name is .png and server stored file extension name is .png [currently is .bin])

As I said, we must not assume that we have a file name available and therefore cannot use the "original" extension. In addition, this would make the file handling logic more complex without providing much benefit to tusd or am I missing something?

[hanjun-lin]

It will be good if the file extension name stored in the server is same as uploaded file. (e.g. uploaded file extension name is .png and server stored file extension name is .png [currently is .bin])

As I said, we must not assume that we have a file name available and therefore cannot use the "original" extension. In addition, this would make the file handling logic more complex without providing much benefit to tusd or am I missing something?

I agree with you. It may a good viewpoint for a protocol and sample code of keeping the file handing logic simple. The file handling logic can be implemented by another agent or API written by whom wants to do further applications.

But the performance and efficiency is not good for production because of the file I/O operating for reading the .info file.

Please explain this thought more. You need a place to save the additional information about the upload and this is exactly why we need it. We cannot simply remove it. Also, if you have bigger uploads, the impact of reading this small file is negligible IMO.

It's not my mean to remove the .info file. In my original simple thoughts, the original file name can be as full or partial of new file name in the server. It will be more efficient without reading the .info file to get the original file name in the server side. It just a simple thoughts. Current implementations and sample codes I think is enough for further applications.

[Acconut]

I agree with you.

👍

It's not my mean to remove the .info file. In my original simple thoughts, the original file name can be as full or partial of new file name in the server. It will be more efficient without reading the .info file to get the original file name in the server side. It just a simple thoughts.

That's a good use case but a very specialized one. In general, I think, people will need more information than just the original file name and therefore have to read the additional data anyway. So I am sorry, but your suggestion won't make it into tusd.