ISTM you could make a struct that records the original file path but embeds an fs.FS and just use that. It doesn’t seem like a common enough use case that you need to worry about someone outside your application passing you an fs.FS of unknown provenance.

That said, maybe there could be an optional method URI() for an FS to implement that returns s3://bucket mem:// file:///path etc.

this looks a bit like poor design, where the thing you test isn't the same as the thing running in production.

fwiw, reflect works

ISTM you could make a struct that records the original file path but embeds an fs.FS and just use that.

This is exactly what I ended up with before filing this issue. I thought it could be useful to have a common way to check if the FS is local and real.

That said, maybe there could be an optional method URI() for an FS to implement that returns s3://bucket mem:// file:///path etc.

Or a Kind() string returning "file", "s3", "testing" or whatever else depending on the implementation.

this looks a bit like poor design, where the thing you test isn't the same as the thing running in production.

Uh, is that a bad thing? After all testing/fstest is a thing. Also, a piece of code may act differently depending on whether the FS is local, instead of Samba, NFS, S3 or any other network file system.

This is easy to do for specific uses. Is it really such a common use case that it should be added to the standard library? Can you show some existing examples that would benefit form this?