Clean up WithResourceMapping

[cimnine]

What does this PR do?

Overhaul of WithResourceMapping().
The methods with string arguments are deprecated and replaced with the following methods. These signatures are explicit with regard to the target path being a file or directory path.

WithResourceMapping(FileInfo, DirectoryInfo, UnixFileModes fileMode = Unix.FileMode644);
WithResourceMapping(FileInfo, FileInfo, UnixFileModes fileMode = Unix.FileMode644);
WithResourceMapping(DirectoryInfo, DirectoryInfo, UnixFileModes fileMode = Unix.FileMode644);
WithResourceMapping(byte[], FileInfo, UnixFileModes fileMode = Unix.FileMode644);
WithResourceMapping(Uri, FileInfo, UnixFileModes fileMode = Unix.FileMode644);
WithResourceMapping(Uri, DirectoryInfo, UnixFileModes fileMode = Unix.FileMode644);

Why is it important?

With the previous API, it wasn't consistent whether the target string path is a directory or a file.

Related issues

• Closes [Bug]: Copy a file WithResourceMapping leads to an (empty) directory in the container #1486

[netlify]

✅ Deploy Preview for testcontainers-dotnet ready!

Name	Link
🔨 Latest commit	016630f
🔍 Latest deploy log	https://app.netlify.com/projects/testcontainers-dotnet/deploys/688db5b0647fa40008870858
😎 Deploy Preview	https://deploy-preview-1497--testcontainers-dotnet.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[HofmeisterAn]

Thanks for taking care of this! Could you please remove/revert the unnecessary changes (like extra whitespace, line breaks, etc.)? That would make the review much easier 🙏.

[cimnine]

Could you please remove/revert the unnecessary changes

Sure, sorry for that. I also rebased while at it.

[HofmeisterAn]

Thanks for the PR 🙏.

After taking a closer look at the PR, I remembered why we didn't introduce this earlier.
The issue with FileSystemInfo implementations (DirectoryInfo, FileInfo) is that they obviously refer to the underlying OS.

On Windows, some of the tests fail because files can't be copied into the container properly.
For example, using new FileInfo("/test.txt") ends up referring to C:\test.txt, which isn't what we want (as target).

We need an abstraction that works with the target container OS as well, unfortunately.

[HofmeisterAn]

Suggested change

	return WithResourceMapping(new FileResourceMapping(source.AbsolutePath, target.FullName, fileMode));
	return WithResourceMapping(new FileInfo(source.AbsolutePath), target, fileMode);

[HofmeisterAn]

I believe this will copy the file to the wrong place.

[HofmeisterAn]

Many of the methods are tested here (this supports HTTP too):

testcontainers-dotnet/tests/Testcontainers.Platform.Linux.Tests/TarOutputMemoryStreamTest.cs

Line 118 in 6c5b160

public async Task TestFileExistsInContainer()

[cimnine]

On Windows, some of the tests fail because files can't be copied into the container properly.
For example, using new FileInfo("/test.txt") ends up referring to C:\test.txt, which isn't what we want (as target).

Pity. What about providing our own abstraction for File- vs. Directory-Paths? Basically a Record containing a single String. I imagine two classes with each a static helper like FilePath.of("/blabla/file") and DirPath.of("/jiiihaaa/dir"). And/or an extension method for String like "/path/to/file".AsFile() and "/path/to/dir".AsDir() (comparable to the approach Flurl takes).

[HofmeisterAn]

Sounds like a good idea 👍. We probably just need something like this (and the equivalent for directory):

public readonly record struct FilePath
{
    private FilePath(string value)
    {
        Value = Unix.Instance.NormalizePath(value); // This method already exists in Testcontainers.
    }

    public string Value { get; }

    public static FilePath Of(string path) => new FilePath(path);
}

WDYT?