From 76e86fc6e3523d28e8db00e7b10c33c553d996b8 Mon Sep 17 00:00:00 2001 From: Jeff King Date: Mon, 24 Nov 2014 13:40:44 -0500 Subject: fsck: notice .git case-insensitively We complain about ".git" in a tree because it cannot be loaded into the index or checked out. Since we now also reject ".GIT" case-insensitively, fsck should notice the same, so that errors do not propagate. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano --- fsck.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'fsck.c') diff --git a/fsck.c b/fsck.c index 99c049767..918bf9a31 100644 --- a/fsck.c +++ b/fsck.c @@ -175,7 +175,7 @@ static int fsck_tree(struct tree *item, int strict, fsck_error error_func) has_dot = 1; if (!strcmp(name, "..")) has_dotdot = 1; - if (!strcmp(name, ".git")) + if (!strcasecmp(name, ".git")) has_dotgit = 1; has_zero_pad |= *(char *)desc.buffer == '0'; update_tree_entry(&desc); -- cgit v1.2.1 From a18fcc9ff22b714e7df30c400c05542f52830eb0 Mon Sep 17 00:00:00 2001 From: Jeff King Date: Mon, 15 Dec 2014 18:21:57 -0500 Subject: fsck: complain about HFS+ ".git" aliases in trees Now that the index can block pathnames that case-fold to ".git" on HFS+, it would be helpful for fsck to notice such problematic paths. This lets servers which use receive.fsckObjects block them before the damage spreads. Note that the fsck check is always on, even for systems without core.protectHFS set. This is technically more restrictive than we need to be, as a set of users on ext4 could happily use these odd filenames without caring about HFS+. However, on balance, it's helpful for all servers to block these (because the paths can be used for mischief, and servers which bother to fsck would want to stop the spread whether they are on HFS+ themselves or not), and hardly anybody will be affected (because the blocked names are variants of .git with invisible Unicode code-points mixed in, meaning mischief is almost certainly what the tree author had in mind). Ideally these would be controlled by a separate "fsck.protectHFS" flag. However, it would be much nicer to be able to enable/disable _any_ fsck flag individually, and any scheme we choose should match such a system. Given the likelihood of anybody using such a path in practice, it is not unreasonable to wait until such a system materializes. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano --- fsck.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'fsck.c') diff --git a/fsck.c b/fsck.c index 918bf9a31..b49113bf0 100644 --- a/fsck.c +++ b/fsck.c @@ -6,6 +6,7 @@ #include "commit.h" #include "tag.h" #include "fsck.h" +#include "utf8.h" static int fsck_walk_tree(struct tree *tree, fsck_walk_func walk, void *data) { @@ -175,7 +176,7 @@ static int fsck_tree(struct tree *item, int strict, fsck_error error_func) has_dot = 1; if (!strcmp(name, "..")) has_dotdot = 1; - if (!strcasecmp(name, ".git")) + if (!strcasecmp(name, ".git") || is_hfs_dotgit(name)) has_dotgit = 1; has_zero_pad |= *(char *)desc.buffer == '0'; update_tree_entry(&desc); -- cgit v1.2.1 From d08c13b947335cc48ecc1a8453d97b7147c2d6d6 Mon Sep 17 00:00:00 2001 From: Johannes Schindelin Date: Wed, 10 Dec 2014 22:28:27 +0100 Subject: fsck: complain about NTFS ".git" aliases in trees Now that the index can block pathnames that can be mistaken to mean ".git" on NTFS and FAT32, it would be helpful for fsck to notice such problematic paths. This lets servers which use receive.fsckObjects block them before the damage spreads. Note that the fsck check is always on, even for systems without core.protectNTFS set. This is technically more restrictive than we need to be, as a set of users on ext4 could happily use these odd filenames without caring about NTFS. However, on balance, it's helpful for all servers to block these (because the paths can be used for mischief, and servers which bother to fsck would want to stop the spread whether they are on NTFS themselves or not), and hardly anybody will be affected (because the blocked names are variants of .git or git~1, meaning mischief is almost certainly what the tree author had in mind). Ideally these would be controlled by a separate "fsck.protectNTFS" flag. However, it would be much nicer to be able to enable/disable _any_ fsck flag individually, and any scheme we choose should match such a system. Given the likelihood of anybody using such a path in practice, it is not unreasonable to wait until such a system materializes. Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano --- fsck.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'fsck.c') diff --git a/fsck.c b/fsck.c index b49113bf0..0b76de6f6 100644 --- a/fsck.c +++ b/fsck.c @@ -176,7 +176,8 @@ static int fsck_tree(struct tree *item, int strict, fsck_error error_func) has_dot = 1; if (!strcmp(name, "..")) has_dotdot = 1; - if (!strcasecmp(name, ".git") || is_hfs_dotgit(name)) + if (!strcasecmp(name, ".git") || is_hfs_dotgit(name) || + is_ntfs_dotgit(name)) has_dotgit = 1; has_zero_pad |= *(char *)desc.buffer == '0'; update_tree_entry(&desc); -- cgit v1.2.1