Bizarre file ownerships causing failures on MacOS

[mirams]

Simple test that illustrates it - TestFileFinder.hpp

Fails with messages like this:

 ***** TestFileFinder.hpp *****


Entering TestFileFinderOpening
Passed
Entering TestNewer
Passed
Entering TestIsAbsolutePath
Passed
Entering TestDirFinder
Passed
Entering TestHandyFilenameOperations
Passed
Entering TestFaking
Passed
Entering TestRemove
Passed
Entering TestFindMatches
Passed
Entering TestCopying

/home/chaste/src/global/test/TestFileFinder.hpp:361: Error: Test failed: filesystem error: status: Permission denied [/home/chaste/output/TestFileFinder_TestCopyingFolders/TestFileFinder_TestCopying/new_name]
Failed
Entering TestDefaultConstructor
Passed

Failed 1 of 10 tests

Looking at the file it mentions, the folder has some file chown settings no-one has ever seen before!

~/output/TestFileFinder_TestCopyingFolders/TestFileFinder_TestCopying$ ls -ltra
ls: cannot access 'new_name': Permission denied
ls: cannot access 'TestFileFinder.hpp': Permission denied
total 0
-????????? ? ?      ?        ?            ? new_name
-????????? ? ?      ?        ?            ? TestFileFinder.hpp
drwxr-xr-x 4 chaste chaste 128 Jan  9 13:37 sub1
--w------- 1 chaste chaste   0 Jan  9 13:37 .chaste_deletable_folder
drwxr-xr-x 6 chaste chaste 192 Jan  9 13:37 .
drwxr-xr-x 5 chaste chaste 160 Jan  9 13:37

Doing a bit of detective work, I think it is this line which causes it - a call to FileFinder::CopyTo, applied to a directory, only where the source and destination are both somewhere in the testoutput (the bound docker volume).

Under the hood, this only seems to be using std::filesystem::directory_iterator, std::filesystem::create_directory(dest) . Both these seem to work, as the created folders have the right permissions and the tree is constructed right. And then std::filesystem::copy_file on line 305 of FileFinder.cpp must be doing something weird.

Even then it is a bit intermittent, and when I've started with a clean ~/output folder sometimes it works first time, fails second, and sometimes it always fails!

[mirams]

You'll like this, NOT A LOT, but you'll like it.

I swapped from "Apple Virtualization Framework+Rosetta" to "Docker VMM Beta" in Docker Desktop Settings:

and it completely got rid of the above error when running TestFileFinder.hpp! Hooray!

BUT(!)

TestOutputFileHandler is failing on the TS_ASSERT_THROWS_CONTAINS() in here (N.B. on second run it fails in constuctor because it can't wipe the folder because .chaste_deleteable_file isn't present!).:

        // Coverage of the case where we can't open a file for writing
        OutputFileHandler handler6("no_write_access");
        if (PetscTools::AmMaster())
        {
            std::string dir_path =  handler6.GetOutputDirectoryFullPath();
#ifndef _MSC_VER
            // This test can never pass on modern Windows OS! See: http://support.microsoft.com/kb/326549
            // You can't change DIRECTORY attributes
            chmod(dir_path.c_str(), CHASTE_READONLY);
            TS_ASSERT_THROWS_CONTAINS(p_file_stream = handler6.OpenOutputFile("test_file"),
                                      "Could not open file");
#endif
            chmod(dir_path.c_str(), CHASTE_READ_WRITE_EXECUTE);
            fs::remove(dir_path + ".chaste_deletable_folder");
            fs::remove(dir_path);
        }

The comment above about it not working on modern windows seems suspiciously like it might no longer work on modern Mac/virtual file system too...

It also fails on global/test/TestArchivingHelperClasses.hpp:250 which is in, you guessed it, the same #ifndef block:

// Remove write permissions on the archive dir
//Note: changing *directory* permissions and other attributes does not work on Windows
//See http://support.microsoft.com/kb/326549
#ifndef _MSC_VER
...

It also fails in TestHdf5DataWriter (line 1394) in a test that a file is read-only when an exception message should be thrown about it being unwritable, but isn't. Shortly after we call this on it:

chmod(empty.GetAbsolutePath().c_str(), CHASTE_READONLY);

So at least it seems to be failing when we are intentionally trying to chmod and mess with things.

The end result of a Continuous test pack was:

97% tests passed, 14 tests failed out of 403

Label Time Summary:
Continuous_cell_based                      = 2722.11 sec*proc (110 tests)
Continuous_continuum_mechanics             =   9.09 sec*proc (11 tests)
Continuous_crypt                           = 307.07 sec*proc (29 tests)
Continuous_global                          =   7.22 sec*proc (37 tests)
Continuous_heart                           = 365.13 sec*proc (75 tests)
Continuous_io                              =   1.68 sec*proc (6 tests)
Continuous_linalg                          =   1.34 sec*proc (10 tests)
Continuous_lung                            =  25.97 sec*proc (16 tests)
Continuous_mesh                            =  36.28 sec*proc (61 tests)
Continuous_ode                             =   1.81 sec*proc (15 tests)
Continuous_pde                             =  16.29 sec*proc (28 tests)
Continuous_project_IntroToChasteCpp2025    = 615.86 sec*proc (1 test)
Continuous_python                          =   0.91 sec*proc (4 tests)

Total Test time (real) = 4111.42 sec

The following tests FAILED:
          1 - TestArchivingHelperClasses (Failed)
         20 - TestLogFile (Failed)
         25 - TestOutputFileHandler (Failed)
         50 - TestHdf5DataWriter (Failed)
        275 - TestDivisionBiasTrackingModifier (Subprocess aborted)
        285 - TestOffLatticeSimulationWithNodeBasedCellPopulation (Failed)
        382 - TestBidomainTissue (Subprocess aborted)
        383 - TestBidomainProblem (Failed)
        388 - TestExtendedBidomainTissue (Subprocess aborted)
        401 - TestDynamicallyLoadedCellModels (Failed)
        421 - TestMonodomainProblem (Failed)
        423 - TestMonodomainPurkinjeProblem (Failed)
        446 - TestCardiacSimulationArchiver (Failed)
        450 - TestHeartConfig (Failed)
Errors while running CTest

[mirams]

OK, the above was all in the VS Code devcontainer with bound volumes.

If you are in just docker volume with no VS Code and no bindings, then everything passes using the Docker VMM setting.

Docker + bindings but without VSCode gets almost-the-same-but-not-quite failures and goes a teeny bit faster, but still very slow:

98% tests passed, 9 tests failed out of 402

Label Time Summary:
Continuous_cell_based             = 2756.96 sec*proc (110 tests)
Continuous_continuum_mechanics    =   9.06 sec*proc (11 tests)
Continuous_crypt                  = 499.48 sec*proc (29 tests)
Continuous_global                 =   6.77 sec*proc (37 tests)
Continuous_heart                  = 403.34 sec*proc (75 tests)
Continuous_io                     =   2.04 sec*proc (6 tests)
Continuous_linalg                 =   1.31 sec*proc (10 tests)
Continuous_lung                   =  24.19 sec*proc (16 tests)
Continuous_mesh                   =  45.23 sec*proc (61 tests)
Continuous_ode                    =   1.77 sec*proc (15 tests)
Continuous_pde                    =  15.38 sec*proc (28 tests)
Continuous_python                 =   0.72 sec*proc (4 tests)

Total Test time (real) = 3766.48 sec

The following tests FAILED:
	  1 - TestArchivingHelperClasses (Failed)
	 20 - TestLogFile (Failed)
	 25 - TestOutputFileHandler (Failed)
	 50 - TestHdf5DataWriter (Failed)
	401 - TestDynamicallyLoadedCellModels (Failed)
	421 - TestMonodomainProblem (Failed)
	423 - TestMonodomainPurkinjeProblem (Failed)
	446 - TestCardiacSimulationArchiver (Failed)
	450 - TestHeartConfig (Failed)
Errors while running CTest

So it may be that VS Code without bindings, and just right-clicking to download results, may be the most sensible option.

[bdevans]

We could experiment with removing the bind mount for the output folder as I suspect that is the issue but I think the main repo has to be bind mounted into the devcontainer as part of the way VS Code works.