[FileSystem] Bug: When creating chained sym links of different types targeting the other type MockFileSystem in windows doesn't throw

[pw-sgr]

The tests didn't succeed because I used FileSystem.File to create a directory symbolic link.

This was windows exclusive. @vbreuss should I include that behavior in the MockFileSystem? It currently works like linux where theres no difference between symbolic link created through File or Directory.

The goal of Testably.Abstractions is to behave the same as the real file system on all operating systems. So if you say that under Linux there is no difference between a symbolic link to a file and a directory, I would like this to be reflected in the MockFileSystem (I work under Windows, so testing the Linux behaviour for me is always done in the pipelines).

Maybe you could create a separate issue for this, @pw-sgr?

Originally posted by @vbreuss in #813 (comment)

[pw-sgr]

Linux Mint 22: No difference between File Sym Link and Directory Sym Link
Windows 11 Pro 24H2 26100.4652: System.IO.IOException: The directory name is invalid. : ''

[pw-sgr]

I'll take a look on monday if there's a way to differentiate if it's a file sym link or dir sym link via the location/container in InMemoryStorage.ResolveLinkTarget

[pw-sgr]

It is possible, but we would need to retrieve the IStorageContainer and then compare the containers Type property

InMemoryStorage.ResolveLinkTarget:

	public IStorageLocation? ResolveLinkTarget(IStorageLocation location,
		bool returnFinalTarget = false)
	{
		if (!_containers.TryGetValue(location, out IStorageContainer? initialContainer)
		    || initialContainer.LinkTarget == null)
		{
			return null;
		}

		IStorageLocation? nextLocation =
			_fileSystem.Storage.GetLocation(initialContainer.LinkTarget);
		
                // CHANGE
		if (!_containers.TryGetValue(nextLocation, out IStorageContainer? container))
		{
			return nextLocation;
		}

                // CHANGE
		if (_fileSystem.SimulationMode == SimulationMode.Windows && initialContainer.Type != container.Type)
		{
			throw new Exception("Some exception");
		}
		
		if (returnFinalTarget && container.LinkTarget != null)
		{
			nextLocation = ResolveFinalLinkTarget(container, location);
		}
		
		return nextLocation;
	}

InMemoryStorage.ResolveFinalLinkTarget:

	private IStorageLocation? ResolveFinalLinkTarget(IStorageContainer container,
		IStorageLocation originalLocation)
	{
		int maxResolveLinks = _fileSystem.Execute.IsWindows ? 63 : 40;
		IStorageLocation? nextLocation = null;
		for (int i = 1; i < maxResolveLinks; i++)
		{
			if (container.LinkTarget == null)
			{
				break;
			}

			nextLocation = _fileSystem.Storage.GetLocation(container.LinkTarget);
			if (!_containers.TryGetValue(nextLocation,
				out IStorageContainer? nextContainer))
			{
				return nextLocation;
			}

                        // CHANGE
			if (_fileSystem.SimulationMode == SimulationMode.Windows && container.Type != nextContainer.Type)
			{
				throw new Exception("Some exception");
			}

			container = nextContainer;
		}

		if (container.LinkTarget != null)
		{
			throw ExceptionFactory.FileNameCannotBeResolved(
				originalLocation.FullPath);
		}

		return nextLocation;
	}

[pw-sgr]

@vbreuss what do you think, apart from the rough edges like the placeholder exceptions? Since nextContainer is always retrieved not just when returnFinalTarget is true it loses some speed.

[vbreuss]

I think it is much more important to trust the mock file system (it behaves the same as the real file system), than for squeezing out the last bit of speed, so please go forward with this change, @pw-sgr...

[github-actions]

This is addressed in release v4.3.2.