projects/datalad/bugs-done/2 mac crippled FS: Unable to remove all writeyohhttp://git-annex.branchable.com/projects/datalad/bugs-done/2_mac_crippled_FS__58___Unable_to_remove_all_write/git-annexikiwiki2023-01-05T17:30:31Zcomment 1http://git-annex.branchable.com/projects/datalad/bugs-done/2_mac_crippled_FS__58___Unable_to_remove_all_write/comment_1_22a1f4b025a6046e4d11f90590a6e4bd/joey2023-01-05T17:30:31Z2021-09-01T13:48:57Z
<p>Seems that mounting that way on OSX results in a FS where files are always mode
777 and the permissions cannot be changed.</p>
<p>When I tried using git-annex on such a FS, I saw:</p>
<pre><code>datalads-imac:x joey$ git annex init
init
Detected a filesystem without fifo support.
Disabling ssh connection caching.
Filesystem allows writing to files whose write bit is not set.
Detected a crippled filesystem.
</code></pre>
<p>And it skips the new permissions check when on a crippled filesystem.</p>
<p>But in that that test run, it seems it is failing to detect a crippled
filesystem. Both because of the failure and also the test suite does
not even run the "v8 unlocked" tests when it detects a crippled filesystem.</p>
<p>Is the test suite running as root? Looks like probably yes. Running as
root prevents detecting the issue that made it use a crippled FS above. And it
seems that, when a FAT fs is mounted on OSX that way, symlinks actually work
(!!!) so the other crippled FS tests also don't notice a problem.</p>
<p>So, the fix should be for init to also test if it can remove the write
bits from a file, and it should try that test even when root.</p>
comment 2http://git-annex.branchable.com/projects/datalad/bugs-done/2_mac_crippled_FS__58___Unable_to_remove_all_write/comment_2_71e985981c14780cc172a07beb0e9854/yarikoptic2023-01-05T17:30:31Z2021-09-01T16:22:22Z
<blockquote><p>Is the test suite running as root? Looks like probably yes.</p></blockquote>
<p>FWIW, it is a <code>runner</code> user <a href="https://github.com/datalad/git-annex/pull/76/checks?check_run_id=3486443350#step:8:1">ref</a> (did in a temp <a href="https://github.com/datalad/git-annex/pull/76">PR</a>) who is not <code>root</code> but is part of the <code>admin</code> group thus with super privileges indeed (that is why I guess we can also use <code>hdiutil</code> directly to mount that crippled FS).</p>
comment 3http://git-annex.branchable.com/projects/datalad/bugs-done/2_mac_crippled_FS__58___Unable_to_remove_all_write/comment_3_ac3fe75560c020015ecca615cf0e7abe/joey2023-01-05T17:30:31Z2021-09-02T16:22:56Z
OSX test is still failing after that fix, reopened.
comment 4http://git-annex.branchable.com/projects/datalad/bugs-done/2_mac_crippled_FS__58___Unable_to_remove_all_write/comment_4_3bdf724f5e9203424b7cb5630fb49a46/joey2023-01-05T17:30:31Z2021-09-02T16:26:14Z
<p>My prior analysis seems right, as far as it running as root would go, but it is
not running as root. So I missed something.</p>
<p>The test failures are both of <code>git-annex import</code>.
Otherwise locking down files does succeed. The difference with import
must be that the file located in a directory outside the repository.</p>
<p>Aha... The test suite is being run with TEMPDIR set to the crippled FS,
but <code>.t</code> is in another, non-crippled FS. A very smart idea to test that,
although I think this import test is the only one that actually uses
TEMPDIR. (Reading the workflow file, I think it was maybe expected that
all the tests would run in TEMPDIR, but they don't; <code>git-annex test</code>
writes to <code>./.t</code>, other than this one test.</p>
<p>When the import directory is on a crippled FS, and the repo
is not, it will think the FS is not crippled. Then it fails
to remove write perms from the file while it is in the import
directory, and the perm check then fails.</p>
<p>So, I think it should skip the perm check when doing the initial lockdown
of the file it's going to import.</p>
comment 5http://git-annex.branchable.com/projects/datalad/bugs-done/2_mac_crippled_FS__58___Unable_to_remove_all_write/comment_5_46acb87752c0f0574d8f3b91fdfb1697/joey2023-01-05T17:30:31Z2021-09-02T17:39:20Z
Ok, fixed some more, hopefully all the way this time..