fix: do not remove mounted files directory, fixes #6188

[rfay]

The Issue

• Target upload_dirs do not have any files in them inside container, when using mutagen after a ddev pull pantheon or ddev import-files #6188

It turns out that with mutagen enabled, all of our import-files and ddev pull actions will fail because the host-side target files directory gets removed during the import process.

When mutagen is enabled, then each of the upload_dirs are bind-mounted from the host. In this situation, the existing code removes the host-side directory, breaking the bind-mount because the host source dir has been removed.

ddev restart fixes everything, but that's just a workaround.

How This PR Solves The Issue

• Purge the source directory instead of removing it
• Use otiai10/copy to do the copying instead of fileutil.CopyDir (which requires the target directory not to exist)

Manual Testing Instructions

With a Drupal (and all other CMS) directory, and with mutagen enabled, ddev import-files --src=<tarball> and verify that the files get loaded into the target directory

Same with ddev pull <anything>

Automated Testing Overview

• I improved TestDdevImportFiles to verify with import-files that this succeeds. Our tests should have caught this before, especially in the import-files testing. It makes sense that we didn't catch it in the TestPantheonPull test because we don't use mutagen there.

Related Issue Link(s)

Release/Deployment Notes

[github-actions]

Download the artifacts for this pull request:

• all-ddev-executables.zip
• ddev-linux-amd64.zip
• ddev-linux-arm64.zip
• ddev-macos-amd64.zip
• ddev-macos-arm64.zip
• ddev-windows-amd64-installer.zip

See Testing a PR.

[stasadev]

This looks great to me!

---

Not related to this PR, but:

Use otiai10/copy to do the copying instead of fileutil.CopyDir (which requires the target directory not to exist)

I'm not sure, but maybe we can use a wrapper for otiai10/copy in fileutil because it's not always obvious in the code why it's used, and if we wrap it, we don't need to do an import for that library in many places.

[rfay]

I'm not sure, but maybe we can use a wrapper for otiai10/copy in fileutil because it's not always obvious in the code why it's used, and if we wrap it, we don't need to do an import for that library in many places.

otiai10/copy is so much better than the ancient home-grown one we use in general. I just haven't been willing to disrupt so much code by replacing the old one. It would be reasonable to do that with a wrapper.

[stasadev]

Yes, I meant not to replace fileutil.CopyDir, but to add some new function so that it can be used in the same way.

[rfay]

I think otaia10/copy may even have an option in its options for that, so we could do that cleanly. It think it might be better to just disrupt everything and get rid of the current behavior (requiring deleted directory)