TDD - How to test .Read() without .Write()?

We're trying to use TDD to create our system and we've come to a situation where we can't figure out what the right TDD course of action is.

We've hidden the file IO behind an interface like so:

public interface IFileIo
{
    byte[] Read(string fileName);
    void Write(string filename, byte[] data);
}

and now we're creating an InMemoryFileIo that we can use in place of the real SystemFileIo class that we'll use for production.

We want to make sure this InMemoryFileIo works correctly and there may be cases where we want to use it in lieu of the actual file system, so it should be "production quality".

The question is, doing everything the "right TDD way", how can we create a test for either .Read() or .Write() where they don't depend on each other?

In order to test that .Read() worked correctly, we would have needed to successfully made a call to .Write() first, and similarly, to test that .Write() works correctly we would then need to call .Read() afterwards. By doing this, we've actually created the same test twice (arrange, then a write, then a read, then asserts).

Lets say we have two tests, one that tests .Read() and one that tests .Write(). If either of those functions doesn't work, then both tests fail. This violates the principle that "A test should only have one reason to fail".

The example here is for file IO, but this same question has come up for us when working with a database (test put without get).