File size from stream

[jsilvestre]

Hello and thank your work, it's going to be very helpful!

I find difficulties understanding what "part.byteCount" is since it changes in function of the part orders. I get the correct file size if the file is the last part (as stated in the documentation) but I don't understand why it's not the correct file size if it's not the case; and can't figure how to compute it if it's not the last part (and the part doesn't have a content-length header).

Thanks in advance for your answer.
Cheers!

[jsilvestre]

Thanks to a colleague, I figured why it's the case: we know the body request length, if it's the last part of the request, we can deduce the file size. I close the issue since I believe there is no way to solve my issue ;-)

[dougwilson]

@jsilvestre yea, if the request does not list the content-length of each part (that's optional and up to the client) then we don't know the byteCount of the part until after it is fully read (but we leave reading the part to you) :)

[caub]

byteCount - assuming that this is the last part in the request, this is the size of this part in bytes. You could use this, for example, to set the Content-Length header if uploading to S3. If the part had a Content-Length header then that value is used here instead.`

so if I send 3 files 5kb 30kb 20kb, it seems the first part.byteCount is 55kB (total), the second is 50kb and last is 20kb

so if I need to know the size of a part, I can know it in the next part event with previewPart.byteCount - part.byteCount (or close when it's the last one) right?

Well nvm, they could be stored in part.name, but actually I'll save on disk and read size there