From mboxrd@z Thu Jan 1 00:00:00 1970 From: john at keeping.me.uk (John Keeping) Date: Tue, 8 Mar 2016 14:59:08 +0000 Subject: [PATCH 1/1] scan-tree: handle error in git_config_from_file() In-Reply-To: <20160308155422.1c529572@leda.localdomain> References: <1457445106-17365-1-git-send-email-list@eworm.de> <20160308141135.GC17523@serenity.lan> <20160308152623.2104c4ca@leda.localdomain> <20160308143614.GD17523@serenity.lan> <20160308155422.1c529572@leda.localdomain> Message-ID: <20160308145908.GE17523@serenity.lan> On Tue, Mar 08, 2016 at 03:54:22PM +0100, Christian Hesse wrote: > John Keeping on Tue, 2016/03/08 14:36: > > On Tue, Mar 08, 2016 at 03:26:23PM +0100, Christian Hesse wrote: > > > John Keeping on Tue, 2016/03/08 14:11: > > > > On Tue, Mar 08, 2016 at 02:51:46PM +0100, Christian Hesse wrote: > > > > > From: Christian Hesse > > > > > > > > > > Signed-off-by: Christian Hesse > > > > > > > > Is this solving a particular problem or did you just notice that the > > > > return value is ignored? > > > > > > > > I don't think returning when this fails is correct because we've already > > > > added the repository to the list by this point and a lot of the > > > > remaining code in this function will do something sensible even if > > > > git_config_from_file() fails. > > > > > > > > In fact, git_config_from_file() sets the die_on_error flag for > > > > do_config_from() so the only case that gives us an error here is if the > > > > config file cannot be opened. I don't think it's unreasonable to print > > > > an error if that happens but bailing out of the function at this point > > > > is wrong. > > > > > > Ok, probably you are right... > > > > > > Actually I do have a particular problem, but it is not solved by > > > this patch. :-p Just stumbled and thought it is a good idea. > > > > > > I have a repository that has a config with bad permissions, so http > > > server's user can not read it. cgit does not print http headers and http > > > server bails out with error 500. What path does it take? > > > > Hmm... bad permissions should result in fopen(2) failing, which would > > take the path altered in your patch. > > > > Can you run cgit as the http server's user from a terminal like this: > > > > CGIT_CONFIG=/path/to/cgitrc QUERY_STRING=url=/ cgit > > > > ? It might produce an error message that your http server isn't > > logging. > > It gives: > > Error reading config /path/to/repository.git/config: Permission denied (13) > fatal: unable to access '/path/to/repository.git/config': Permission denied > > Looks like this is fatal in git... Is that when listing repositories or when trying to display that specific repo? I suspect that's a result of prepare_repo_cmd() setting up for a specific repository.