Upload Issues #3131

@DarrenRainey commented on GitHub (Apr 3, 2019):

Yeah that's strange also due to its random nature its hard for me to debug, I've found that the operating system I use to upload the file doesn't matter much since sometimes the same file can still have problem on both windows and linux so I'm guessing this is a server side issue.

Here some other links to people having similar issues with GO:
https://stackoverflow.com/questions/33771167/handle-file-uploading-with-go
https://github.com/seanmonstar/reqwest/issues/252

@DarrenRainey commented on GitHub (Apr 3, 2019): Yeah that's strange also due to its random nature its hard for me to debug, I've found that the operating system I use to upload the file doesn't matter much since sometimes the same file can still have problem on both windows and linux so I'm guessing this is a server side issue. Here some other links to people having similar issues with GO: https://stackoverflow.com/questions/33771167/handle-file-uploading-with-go https://github.com/seanmonstar/reqwest/issues/252

GiteaMirror commented

@zeripath commented on GitHub (Apr 4, 2019):

I'm not sure what's going on here.

Is your Gitea behind a reverse proxy like Nginx or Apache? Could that be responsible?

@zeripath commented on GitHub (Apr 4, 2019): I'm not sure what's going on here. Is your Gitea behind a reverse proxy like Nginx or Apache? Could that be responsible?

GiteaMirror commented

@zeripath commented on GitHub (Apr 4, 2019):

Hmm there was a bug in go 1.5.3 to do with multipart reading. I guess we're going to have to inspect the code. Is it possible for you to attach a bad file to this issue?

I'm suspicious that what's happening is to do with detection of the boundary marker.

@zeripath commented on GitHub (Apr 4, 2019): Hmm there was a bug in go 1.5.3 to do with multipart reading. I guess we're going to have to inspect the code. Is it possible for you to attach a bad file to this issue? I'm suspicious that what's happening is to do with detection of the boundary marker.

GiteaMirror commented

@DarrenRainey commented on GitHub (Apr 4, 2019):

My gitea is in a chroot on my local machine, I'll try and make a bad file so we can replicate this but as mentioned sometimes it will work and somethings it won't with no explanation.

@DarrenRainey commented on GitHub (Apr 4, 2019): My gitea is in a chroot on my local machine, I'll try and make a bad file so we can replicate this but as mentioned sometimes it will work and somethings it won't with no explanation.

GiteaMirror commented

@DarrenRainey commented on GitHub (Apr 4, 2019):

This is a test image which seems to ~~reliability~~ generate the problem for me so far:
bugged-png.tar.gz

Edit: Apparently uploading then downloading it again from github has fixed it somehow? so maybe its an issue with how the file is handled (also I've checked that no other programs are accessing the file at the time of upload and I've made local copies all of which have the same error so I'm thinking that maybe its an issue with how the file is parsed in the uploader)

@DarrenRainey commented on GitHub (Apr 4, 2019): This is a test image which seems to ~~reliability~~ generate the problem for me so far: [bugged-png.tar.gz](https://github.com/go-gitea/gitea/files/3044076/bugged-png.tar.gz) Edit: Apparently uploading then downloading it again from github has fixed it somehow? so maybe its an issue with how the file is handled (also I've checked that no other programs are accessing the file at the time of upload and I've made local copies all of which have the same error so I'm thinking that maybe its an issue with how the file is parsed in the uploader)

GiteaMirror commented

@ghost commented on GitHub (Apr 24, 2019):

Is it possible for you to attach a bad file to this issue?
I'm suspicious that what's happening is to do with detection of the boundary marker.

I don't believe it's file related and it's more an issue with Go or something.
Right now I tried to upload 5 pdf files and they all errored with the same FormFile: multipart: NextPart: EOF message. Waited 2 or 3 minutes, refreshed the page, tried again and they all succeeded.

@ghost commented on GitHub (Apr 24, 2019): > Is it possible for you to attach a bad file to this issue? I'm suspicious that what's happening is to do with detection of the boundary marker. I don't believe it's file related and it's more an issue with Go or something. Right now I tried to upload 5 `pdf` files and they all errored with the same `FormFile: multipart: NextPart: EOF` message. Waited 2 or 3 minutes, refreshed the page, tried again and they all succeeded.

GiteaMirror commented

@lafriks commented on GitHub (Apr 25, 2019):

Can you reproduce that in try.gitea.io?

@lafriks commented on GitHub (Apr 25, 2019): Can you reproduce that in try.gitea.io?

GiteaMirror commented

@ghost commented on GitHub (Apr 25, 2019):

This a totally random and seldom happening issue. Can't reproduce it anywhere. It's a non-stopper, tho. Just try later and it works.

@ghost commented on GitHub (Apr 25, 2019): This a totally random and seldom happening issue. Can't reproduce it anywhere. It's a non-stopper, tho. Just try later and it works.

GiteaMirror commented

@stale[bot] commented on GitHub (Jun 24, 2019):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

@stale[bot] commented on GitHub (Jun 24, 2019): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

GiteaMirror commented

@pditommaso commented on GitHub (Jun 26, 2019):

Still happening with Gitea 1.8.1

@pditommaso commented on GitHub (Jun 26, 2019): Still happening with Gitea 1.8.1

GiteaMirror commented

@ghost commented on GitHub (Sep 9, 2019):

And with 1.9.0, as well. A minute later, tried again and it worked.
To clarify things better, this happens right away after adding a file, without even getting to the action of uploading it.

@ghost commented on GitHub (Sep 9, 2019): And with 1.9.0, as well. A minute later, tried again and it worked. To clarify things better, this happens right away after adding a file, without even getting to the action of uploading it. ![file-add-error](https://user-images.githubusercontent.com/9649385/64530225-80751f00-d304-11e9-941c-c8c3e60b81e3.png)

GiteaMirror commented

@jcsnider commented on GitHub (Sep 12, 2019):

While this might not be a 'proper' fix, I found that changing

file, header, err := ctx.Req.FormFile("file")

to

ctx.Req.ParseMultipartForm(32 << 20)
file, header, err := ctx.Req.FormFile("file")

in /routers/repo/attachment.go and it seems to have solved the problem for me.

The idea came from here. The author states that the ParseMultipartForm function takes the maxMemory argument. After you call ParseMultipartForm, the file will be saved in the server memory with maxMemory size. If the file size is larger than maxMemory, the rest of the data will be saved in a system temporary file. You can use r.FormFile to get the file handle...

This is my first experience with Go, and I have no idea if this solution is actually valid or what the repercussions might be at this point. Just sharing in case it helps.

@jcsnider commented on GitHub (Sep 12, 2019): While this might not be a 'proper' fix, I found that changing ``` file, header, err := ctx.Req.FormFile("file") ``` to ``` ctx.Req.ParseMultipartForm(32 << 20) file, header, err := ctx.Req.FormFile("file") ``` in /routers/repo/attachment.go and it seems to have solved the problem for me. The idea came from [here](https://astaxie.gitbooks.io/build-web-application-with-golang/en/04.5.html). The author states that the ParseMultipartForm function takes the maxMemory argument. After you call ParseMultipartForm, the file will be saved in the server memory with maxMemory size. If the file size is larger than maxMemory, the rest of the data will be saved in a system temporary file. You can use r.FormFile to get the file handle... This is my first experience with Go, and I have no idea if this solution is actually valid or what the repercussions might be at this point. Just sharing in case it helps.

GiteaMirror commented

@ghost commented on GitHub (Sep 23, 2019):

Also, in the mean time, I found that no waiting is needed. When the error happens, hitting Ctrl+F5 to refresh the page from origin, seems to fix it.

@ghost commented on GitHub (Sep 23, 2019): Also, in the mean time, I found that no waiting is needed. When the error happens, hitting <kbd>Ctrl</kbd>+<kbd>F5</kbd> to refresh the page from origin, seems to fix it.

GiteaMirror commented