Error 500 when rendering web view of repository: unknown git object mode 40755

[hollie]

Description

When trying to access the web interface to view a repository, I get an error 500 error message.

The log in gitea shows the following error:

...ers/web/repo/view.go:803:renderDirectoryFiles() [E] [63249040] ListEntries: unknown mode: 40755

Regular cloning of the git repository via SSH works fine, and the file permissions of the repository in the filesystem also look like all is OK.

Gitea Version

1.17.2

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

https://gist.github.com/hollie/bd9a1997a5954803fac0fb3caef9ba84

Screenshots

No response

Git Version

2.36.2

Operating System

docker image 1.17.2

How are you running Gitea?

Running the docker image of version 1.17.2 with a volume mount to store the settings and repos on Ubuntu 22.04.1 LTS.

I have verified the issue is not host specific by restoring from backup on another host. The same repo has the same issues, while other repositories on the same system/database show normal behaviour.

This issue was not present in previous version of gitea.

Database

SQLite

[wxiaoguang]

Hmm , the problem is that the parser hard-coded modes.

But according to https://git-scm.com/docs/index-format:

9-bit unix permission. Only 0755 and 0644 are valid for regular files.
Symbolic links and gitlinks have value 0 in this field.

Maybe all directories (tree object?) are expected to have mode 40000, not sure how the mode 40755 comes, maybe also related to that git repository itself or the git's unstable behavior?

gitea/modules/git/parse_nogogit.go

Lines 113 to 127 in c18d8d6

	switch string(mode) {
	case "100644":
	entry.entryMode = EntryModeBlob
	case "100755":
	entry.entryMode = EntryModeExec
	case "120000":
	entry.entryMode = EntryModeSymlink
	case "160000":
	entry.entryMode = EntryModeCommit
	case "40000":
	entry.entryMode = EntryModeTree
	default:
	log.Debug("Unknown mode: %v", string(mode))
	return nil, fmt.Errorf("unknown mode: %v", string(mode))
	}

[hollie]

Hey @wxiaoguang,

thank you for looking into the details of this bug report.

Is there anything I can do to help troubleshoot this further? Any specific file permissions in the repo you want me to check or any further logs that I can provide?

Best regards,
Lieven.

[wxiaoguang]

TBH, it's likely related to some git internals, I have no idea about how to debug it easily.

If you'd like to have a try, you could try to find the git object id which causes the crash, and put it into the git cat-file --batch to see what's the output of it. Usually, the directories in the output should all have 40000 mode. If you see 40755 then it means that the data in the repository's git database was unexpected already.

To fix the problem, I think adding a case "40755": could be the easy fix. I will propose a PR to see whether maintainers like the fix.

---

The PR: #21195 , could you try to apply it to see whether the problem could be resolved?

[hollie]

Hey @wxiaoguang,

I rebuilt the docker image from the branch from which you made the pull request and I can confirm the issue I was experiencing is solved with the changes you made.

Thanks a lot for taking the time to look into this! I appreciate it very much.

Best regards,
Lieven.