On Tue, Aug 21, 2012 at 02:10:59AM -0400, Jeff King wrote:
> I think that makes sense. Like this patch?
>
> -- >8 --
> Subject: [PATCH] config: warn on inaccessible files
>
> Before reading a config file, we check "!access(path, R_OK)"
> to make sure that the file exists and is readable. If it's
> not, then we silently ignore it.
>
> For the case of ENOENT, this is fine, as the presence of the
> file is optional. For other cases, though, it may indicate a
> configuration error (e.g., not having permissions to read
> the file). Let's print a warning in these cases to let the
> user know.
And this might be a good follow-on:
-- >8 --
Subject: [PATCH] gitignore: report access errors of exclude files
When we try to access gitignore files, we check for their
existence with a call to "access". We silently ignore
missing files. However, if a file is not readable, this may
be a configuration error; let's warn the user.
For $GIT_DIR/info/excludes or core.excludesfile, we can just
use access_or_warn. However, for per-directory files we
actually try to open them, so we must add a custom warning.
Signed-off-by: Jeff King <peff@xxxxxxxx>
---
dir.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/dir.c b/dir.c
index 240bf0c..4ee16b5 100644
--- a/dir.c
+++ b/dir.c
@@ -397,6 +397,8 @@ int add_excludes_from_file_to_list(const char *fname,
fd = open(fname, O_RDONLY);
if (fd < 0 || fstat(fd, &st) < 0) {
+ if (errno != ENOENT)
+ warn(_("unable to access '%s': %s"), fname, strerror(errno));
if (0 <= fd)
close(fd);
if (!check_index ||
@@ -1311,9 +1313,9 @@ void setup_standard_excludes(struct dir_struct *dir)
home_config_paths(NULL, &xdg_path, "ignore");
excludes_file = xdg_path;
}
- if (!access(path, R_OK))
+ if (!access_or_warn(path, R_OK))
add_excludes_from_file(dir, path);
- if (excludes_file && !access(excludes_file, R_OK))
+ if (excludes_file && !access_or_warn(excludes_file, R_OK))
add_excludes_from_file(dir, excludes_file);
}
--
1.7.12.4.g4e9f38f
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html