On Tue, Jan 24, 2017 at 11:04:21AM +0100, Lars Schneider wrote:
> "fsck: prepare dummy objects for --connectivity-check" seems to
> make t1450-fsck.sh fail on macOS with TravisCI:
>
> Initialized empty Git repository in /Users/travis/build/git/git/t/trash
> directory.t1450-fsck/connectivity-only/.git/
> [master (root-commit) 86520b7] empty
> Author: A U Thor <aut...@example.com>
> 2 files changed, 1 insertion(+)
> create mode 100644 empty
> create mode 100644 empty.t
> override r--r--r-- travis/staff for
> .git/objects/e6/9de29bb2d1d6434b8b29ae775ad8c2e48c5391? (y/n [n]) not
> overwritten
> dangling blob c21c9352f7526e9576892a6631e0e8cf1fccd34d
Looks like "mv" prompts and then fails to move the file (so we get the
dangling blob for the source blob, and fsck doesn't report failure because
we didn't actually corrupt the destination blob).
If I'm understanding the behavior correctly, this violates POSIX, which
says:
1. If the destination path exists, the −f option is not specified, and
either of the following conditions is true:
a. The permissions of the destination path do not permit writing
and the standard input is a terminal.
b. The −i option is specified.
the mv utility shall write a prompt to standard error and read a
line from standard input. If the response is not affirmative,
mv shall do nothing more with the current source_file and go on
to any remaining source_files.
Our stdin isn't a terminal, and we do not specify "-i", so I think it
shouldn't prompt. It also exits with code 0 after failing to move,
which is another surprise.
Here's a patch (tested by me that it works on Linux, but I don't know
for sure that it fixes the Travis problem).
-- >8 --
Subject: [PATCH] t1450: use "mv -f" within loose object directory
The loose objects are created with mode 0444. That doesn't
prevent them being overwritten by rename(), but some
versions of "mv" will be extra careful and prompt the user,
even without "-i".
Reportedly macOS does this, at least in the Travis builds.
The prompt reads from /dev/null, defaulting to "no", and the
object isn't moved. Then to make matters even more
interesting, it still returns "0" and the rest of the test
proceeds, but with a broken setup.
We can work around it by using "mv -f" to override the
prompt. This should work as it's already used in t5504 for
the same purpose.
Signed-off-by: Jeff King <p...@peff.net>
---
t/t1450-fsck.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/t/t1450-fsck.sh b/t/t1450-fsck.sh
index efaf41b68..33a51c9a6 100755
--- a/t/t1450-fsck.sh
+++ b/t/t1450-fsck.sh
@@ -536,7 +536,7 @@ test_expect_success 'fsck --connectivity-only' '
# free to examine the type if it chooses.
empty=.git/objects/e6/9de29bb2d1d6434b8b29ae775ad8c2e48c5391 &&
blob=$(echo unrelated | git hash-object -w --stdin) &&
- mv $(sha1_file $blob) $empty &&
+ mv -f $(sha1_file $blob) $empty &&
test_must_fail git fsck --strict &&
git fsck --strict --connectivity-only &&
--
2.11.0.840.gd37c5973a
