same avatars for everyone after upgrade to v1.1.0

[ghost]

• Gitea version (or commit ref): v1.1.0 (updated from v1.0.2)
• Git version: 2.1.4
• Operating system: Debian 8 (stable)
• Database (use [x]):
  • PostgreSQL
  • MySQL
  • MSSQL
  • SQLite
• Can you reproduce the bug at https://try.gitea.io:
  • Yes (provide example URL)
  • No
  • Not relevant
  • Not really possible
• Log gist: n/a

Description

After replacing my v1.0.2 gitea binary with a new v1.1.0 one and starting gitea, all avatars are the same (it was an avatar of a group). All images itself are still in the avatars folder on disk but gitea only shows one for all accounts (user/groups). I cleared my cache but I had to upload all avatars again to get them connected to all user accounts and groups.

[ptman]

Some of the larger avatar changes was in 80f900e

[ghost]

@ptman This might be the reason but for larger installations this bug can be really annoying, especially if you use avatars to distinguish commits and accounts.

[mjwwit]

The issue is most likely in the migration script which translates the old user-id based avatar filenames to md5 based filenames and updates the DB accordingly. All the filenames are correctly updated, but the database will no longer reference the correct avatar after migrating.

Make sure you keep your db backup from before the migration, as fixing the user avatars without this backup will require manual work!

[ghost]

@mjwwit Well, it is a private instance with 3 accounts so I updated everything manually. Nevertheless one should fix the update script.

[eryx]

got the same bug in my updating, can only rollback to v1.0.2.
hope to add the bugfix in v1.1.1

[WolfgangKluge]

@mjwwit since in the database, I can see the last migrated md5 on all users, I think it's here

gitea/models/migrations/v20.go

Line 61 in 74cde12

user.Avatar = fmt.Sprintf("%x", md5.Sum(bs))

[richmahn]

I'm getting this as well. All my custom avatars (I have 2890 users, many which have custom avatars uploaded) be the same avatar! I added a few Printfs to the Migration v20.go file, migrating up from v15, and I see this:

USER TO UPDATE: 4613, {f295aae8bd4b6dca44ad1c35bcf99ad7 true}
2017/05/07 11:07:51 [I] [SQL] UPDATE `user` SET `avatar` = ?  [f295aae8bd4b6dca44ad1c35bcf99ad7]

As you can see, there is no WHERE condition to set avatar where id = 4613!

[richmahn]

@WolfgangKluge You got the wrong line number there that is causing this, as the UPDATE call wasn't done right, apparently.

gitea/models/migrations/v20.go

Line 66 in 74cde12

_, err = x.ID(userID).Cols("avatar").Update(&user)

As I wrote above, setting the ID to userID doesn't cause it to render a "WHERE id = ?"

[richmahn]

Is this "WHERE" being excluded only happening for MySQL?

Never mind, verified this was doing it in Postgresql too.

[WolfgangKluge]

@richmahn I thought of this common mistake: https://github.com/golang/go/wiki/CommonMistakes#using-goroutines-on-loop-iterator-variables

The line I mentioned is only the first of a sequence..

[lunny]

@richmahn I think you are right. I have sent #1724 and #1729 to fix this and both are merged.

[lunny]

Please feel free to reopen this.