Gitea: Upload Issues

Created on 2 Apr 2019  路  17Comments  路  Source: go-gitea/gitea

  • Gitea version (or commit ref):
  • Git version: 1.7.3
  • Operating system: Debian 9
  • Database (use [x]):

    • [ ] PostgreSQL

    • [ ] MySQL

    • [ ] MSSQL

    • [x ] SQLite

  • Can you reproduce the bug at https://try.gitea.io:

    • [ ] Yes (provide example URL)

    • [ ] No

    • [ ] Not relevant

  • Log gist:

Description

Uploading randomly fails with the message "FormFile: multipart: NextPart: EOF gitea" from the web interface currently I am able to work around this by uploading 2 or more files at a time or sometimes restarting gitea helps after doing a bit of research this seems to be a common problem with the way the go handles file uploading, I've experience this issues with various file types with it being more common when uploading PNG image files to a repo with the web uploader.
...

Screenshots

revieweconfirmed

Most helpful comment

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.

All 17 comments

I'm seeing the same issue (with the same error message) on a random basis and I think it started with Gitea 1.7.0 (the version I'm on).
In my case, it normally happens with a .odt file (OpenOffice Writer) so I don't think the issue is tied to any specific extension.

The first time it happened, I still had the file open (Windows environment) so, after closing it I was able to upload it. Just a moment ago, I tried to upload four times in a row and I got the same error, even with the file closed. But just as I took time to start writing this follow-up, i tried it again and it uploaded just fine.

A similar thing sometimes happens, when I try to send an email from Rainloop, which is part of the same suite of services Teknik provides, along with Gitea. It fails to send a couple of times but if I keep trying, it eventually works. All this to say that, in my case, I connect such errors to the fact that I'm behind a corporate (or some kind of) firewall.

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

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

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

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.

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.

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)

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.

Can you reproduce that in try.gitea.io?

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.

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.

Still happening with Gitea 1.8.1

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

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.

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.

Hi, about this error still happened at gitea. When I upload a file which name is not English.
Like this
image

But if I use Command + Shift + R can upload a file which name is not english. who know the reasons

When I found any reason. Seems it cause by Chrome ServiceWork.js
when I unregister all
image
So finally can work.

So anybody suffered this problem can try it. Maybe in future the chrome can fix it

This problem may cause by http2 reusing established connection.

Was this page helpful?
0 / 5 - 0 ratings