From: Joey Hess <joeyh@joeyh.name>
Date: Thu, 26 Aug 2021 21:25:33 +0000 (-0400)
Subject: comment
X-Git-Tag: archive/raspbian/10.20250416-2+rpi1~1^2~87^2~49
X-Git-Url: https://dgit.raspbian.org/?a=commitdiff_plain;h=ea5e58e3e3fbbe762bed5096a9ee71d67961357e;p=git-annex.git

comment
---

diff --git a/doc/bugs/__34__357_out_of_984_tests_failed__34___on_NFS_lustre_mount/comment_8_1219295230f196c00744058ed3441a98._comment b/doc/bugs/__34__357_out_of_984_tests_failed__34___on_NFS_lustre_mount/comment_8_1219295230f196c00744058ed3441a98._comment
new file mode 100644
index 0000000000..2b49ea9651
--- /dev/null
+++ b/doc/bugs/__34__357_out_of_984_tests_failed__34___on_NFS_lustre_mount/comment_8_1219295230f196c00744058ed3441a98._comment
@@ -0,0 +1,66 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 8"""
+ date="2021-08-26T20:18:05Z"
+ content="""
+From the strace of `git-annex test -p export_import_subdir`,
+I have found what I think is the smoking gun:
+
+	21179 stat(".git/annex/othertmp/foo.0/foo", {st_mode=S_IFREG|0444, st_size=20, ...}) = 0
+	21179 chmod(".git/annex/othertmp/foo.0/foo", 0100644) = 0
+	21179 stat(".git/annex/othertmp/foo.0/foo", {st_mode=S_IFREG|0444, st_size=20, ...}) = 0
+	21179 rename(".git/annex/othertmp/foo.0/foo", "./foo") = 0
+
+This seems like proof that NFS is losing the file permissions. chmod 644
+followed immediately by stat showing the mode is still 444, with nothing
+happening in between according to strace.
+
+The full set of operations on that temp file is:
+
+	21179 unlink(".git/annex/othertmp/foo.0/foo") = -1 ENOENT (No such file or directory)
+	21179 vfork( <unfinished ...>
+	21217 execve("/dartfs-hpc/admin/opt/oldopt/git-annex/8.20200522/bin/cp", ["cp", "--reflink=auto", "-a", ".git/annex/objects/Kj/0x/SHA256E-s20--e394a389d787383843decc5d3d99b6d184ffa5fddeec23b911f9ee7fc8b9ea77/SHA256E-s20--e394a389d787383843decc5d3d99b6d184ffa5fddeec23b911f9ee7fc8b9ea77", ".git/annex/othertmp/foo.0/foo"], 0x7fff09e296f8 /* 77 vars */ <unfinished ...>
+	21179 <... vfork resumed>)              = 21217
+	21217 stat(".git/annex/othertmp/foo.0/foo", 0x7ffc13f0d430) = -1 ENOENT (No such file or directory)
+	21217 newfstatat(AT_FDCWD, ".git/annex/othertmp/foo.0/foo", 0x7ffc13f0d1b0, 0) = -1 ENOENT (No such file or directory)
+	21217 openat(AT_FDCWD, ".git/annex/othertmp/foo.0/foo", O_WRONLY|O_CREAT|O_EXCL, 0400) = 4
+	21217 fstat(4, {st_mode=S_IFREG|0400, st_size=0, ...}) = 0
+	21217 ioctl(4, BTRFS_IOC_CLONE or FICLONE, 3) = -1 EOPNOTSUPP (Operation not supported)
+	21217 write(4, "annexed file content", 20) = 20
+	21217 utimensat(4, NULL, [{tv_sec=1629996169, tv_nsec=810295000} /* 2021-08-26T12:42:49.810295000-0400 */, {tv_sec=1629996169, tv_nsec=810295000} /* 2021-08-26T12:42:49.810295000-0400 */], 0 <unfinished ...>
+	21217 <... utimensat resumed>)          = 0
+	21217 fchmod(4, 0600)                   = 0
+	21217 fsetxattr(4, "system.nfs4_acl", "\0\0\0\3\0\0\0\0\0\0\0\0\0\26\1\211\0\0\0\6OWNER@\0\0\0\0\0\0\0\0\0\0\0\22\0\211\0\0\0\6GROUP@\0\0\0\0\0\0\0\0\0\0\0\22\0\211\0\0\0\tEVERYONE@\0\0", 80, 0) = 0
+	21217 fchmod(4, 0400)                   = 0
+	21217 fsetxattr(4, "system.posix_acl_access", "\2\0\0\0\1\0\4\0\377\377\377\377\4\0\4\0\377\377\377\377 \0\4\0\377\377\377\377", 28, 0) = -1 EOPNOTSUPP (Operation not supported)
+	21217 fchmod(4, 0100444)                = 0
+	21217 close(4)                          = 0
+	21179 stat(".git/annex/othertmp/foo.0/foo",  <unfinished ...>
+	21179 <... stat resumed>{st_mode=S_IFREG|0444, st_size=20, ...}) = 0
+	21179 stat(".git/annex/othertmp/foo.0/foo", {st_mode=S_IFREG|0444, st_size=20, ...}) = 0
+	21179 chmod(".git/annex/othertmp/foo.0/foo", 0100644) = 0
+	21179 stat(".git/annex/othertmp/foo.0/foo", {st_mode=S_IFREG|0444, st_size=20, ...}) = 0
+	21179 rename(".git/annex/othertmp/foo.0/foo", "./foo") = 0
+
+So, cp -a copies the object file to the temp file, leaving it 444 at the end,
+as it should be since the object file had that mode. And the following
+chmod 644 has no effect.
+
+That `nfs4_acl` seems like it contains effectively the permissions of the file,
+which were 444 at that point. Could that xattr override the later chmod?
+
+It would be worth trying this:
+
+	# use runshell to get the same cp that git-annex uses
+	/dartfs-hpc/admin/opt/oldopt/git-annex/8.20200522/runshell
+	echo bar > bar
+	chmod 444 bar
+	cp --reflink=auto -a bar baz
+	chmod 644 baz
+	ls -l baz
+
+If preserving the `nfs4_acl` is indeed the problem, then a fix in git-annex
+might be possible. (Even though this feels like a NFS bug) 
+Replace `cp -a` with `cp -dR --preserve=mode,ownership,timestamps`
+so omitting the xattr preservation.
+"""]]