Please describe the problem.
Somewhat not relevant details: We have freeze/thaw scripts configured at the level of a user
When operating on POSIX compliant filesystem (not ACL nfs4 one), our freeze/thaw scripts fail -- exit with non-0:
[f006rq8@discovery-01 ds000003-qc]$ /dartfs/rc/lab/D/DBIC/DBIC/archive/bin-annex/thaw-content code
Operation to request attribute not supported: code
Operation to request attribute not supported: code
Failed while inserting ACE(s).
An error occurred during recursive file tree walk.
[f006rq8@discovery-01 ds000003-qc]$ echo $?
1
but git-annex seems to not care and proceeds forward
[f006rq8@discovery-01 ds000003-qc]$ git annex version
git-annex version: 10.20240831+git21-gd717e9aca0-1~ndall+1
[f006rq8@discovery-01 ds000003-qc]$ dd if=/dev/random of=binary count=10
0+10 records in
0+1 records out
366 bytes copied, 3.99037 s, 0.1 kB/s
[f006rq8@discovery-01 ds000003-qc]$ file binary
binary: data
[f006rq8@discovery-01 ds000003-qc]$ git annex add binary
add binary
Operation to request attribute not supported: binary
Operation to request attribute not supported: /scratch/repro-AXDLDiY/ds000003-qc/binary
Failed to instantiate ACL.
An error occurred during recursive file tree walk.
100% 366 B 582 KiB/s 0s
Operation to request attribute not supported: .git/annex/objects/mj/mj/MD5E-s366--023ff41f7d20c35b2d78c69aa3ce088b
Operation to request attribute not supported: .git/annex/objects/mj/mj/MD5E-s366--023ff41f7d20c35b2d78c69aa3ce088b
Failed while inserting ACE(s).
An error occurred during recursive file tree walk.
Operation to request attribute not supported: .git/annex/objects/mj/mj/MD5E-s366--023ff41f7d20c35b2d78c69aa3ce088b/MD5E-s366--023ff41f7d20c35b2d78c69aa3ce088b
Operation to request attribute not supported: /scratch/repro-AXDLDiY/ds000003-qc/.git/annex/objects/mj/mj/MD5E-s366--023ff41f7d20c35b2d78c69aa3ce088b/MD5E-s366--023ff41f7d20c35b2d78c69aa3ce088b
Failed to instantiate ACL.
An error occurred during recursive file tree walk.
Operation to request attribute not supported: .git/annex/objects/mj/mj/MD5E-s366--023ff41f7d20c35b2d78c69aa3ce088b
Operation to request attribute not supported: /scratch/repro-AXDLDiY/ds000003-qc/.git/annex/objects/mj/mj/MD5E-s366--023ff41f7d20c35b2d78c69aa3ce088b
add binary ok
(recording state in git...)
[f006rq8@discovery-01 ds000003-qc]$ echo $?
0
even though it is like a "feature" for us, so that the same freeze/thaw could be specified at user level, I think generally this is not a desired behavior -- if underlying freeze/thaw script fails, git-annex also should fail!
Given the number of different ways freezeContent is called, it would be very difficult to implement error unwinding for it. So a failure would leave things in a potentially unusual state. For example a failure during
git-annex addat one point would leave the file moved into the repository, but without an annex symlink pointing to it.Or in some cases, freezeContent is the last thing that is done, so failing would leave it in the same state as not failing.
Looking at this another way, there are two ways a freezecontent hook can fail:
git-annex cannot detect the first case. So there does not seem to be much benefit to complicating git-annex to detect the second case and handle it specially.
Regular lock down of files by removing permissions can also fail, in an expected way, in a shared repository when the "wrong" user is running git-annex .
git-annex fsckdeals with that by trying again to freeze the content and checking if the file has the desired permission, and warning if not.Since fsck does run the freeze hook, it will display those error messages again, which at least will remind the user that the hook is broken. And if they fix it, fsck will freeze the content.