From mboxrd@z Thu Jan 1 00:00:00 1970 From: john at keeping.me.uk (John Keeping) Date: Tue, 8 Mar 2016 15:05:21 +0000 Subject: [PATCH 1/1] scan-tree: handle error in git_config_from_file() In-Reply-To: <20160308160159.349a034d@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> <20160308145908.GE17523@serenity.lan> <20160308160159.349a034d@leda.localdomain> Message-ID: <20160308150521.GF17523@serenity.lan> On Tue, Mar 08, 2016 at 04:01:59PM +0100, Christian Hesse wrote: > John Keeping on Tue, 2016/03/08 14:59: > > 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. > > Listing repositories works. This is when displaying the repository with > bad/denied config file. I don't think we can work around that without adding a load of extra checks before calling setup_git_directory_gently(), which would allow us to at least print a more obvious error message. The problem is that git_config_early() dies if the file cannot be accessed and there is no way for us to read from a repository without going through that function.