indicate read-only / immutable filesystems

[efiop]

These are some early thoughts, but I just wanted to share in case anyone else will find this useful or will have any thoughts/comments.

Some fsspec filesystems might raise EROFS error if you try to actively write something to them, but it would be nice to indicate that for the whole filesystem without having to try to write to it. My logic here is following ro mount options in real filesystems.

The first example that comes to mind is gitfs, where, given a rev, nothing can change while the filesystem exists. Or, say, a tar archive or ipfs. So it would be useful if they could define fs.read_only set to True.

The next interesting property here might be immutability, meaning that litteraly nothing can ever change. For example gitfs on a branch is read-only, but not immutable as the branch can change, but gitfs with sha is read-only and immutable. So it would be useful if it could define fs.immutable as smth like return is_sha(self.rev).

This allows making some useful assumptions about the state of the filesystem, like not having to worry that something will change during a session or straight up not caring about metadata checks at all for immutable filesystems.

[martindurant]

I have no objection. The superclass implementation would presumably default to writable. You seem to suggest this would behave like an instance attribute or property - do you imagine a user wishing to open a writable filesystem in read-only mode?

[efiop]

The superclass implementation would presumably default to writable.

Yep, read_only would default to False and immutable to False as well. Maybe one could argue about potential defaults like None or NotImplementedError might be considered, but I don't think that matters much and False is a safe simple default.

You seem to suggest this would behave like an instance attribute or property

Correct. There is also a case for class attribute for some filesystems that are just always read-only (e.g. gitfs so far) and/or immutable (ipfs?), but again that probably doesn't matter at this point and instance property is totally sufficient for all cases that might happen.

do you imagine a user wishing to open a writable filesystem in read-only mode?

Thank you, that's a very good question, I absolutely forgot to mention that! Yes, that's an obvious potential use case, but I don't think I've ever seen requests for it so far (not that read_only/immutable is popular, but at least we have a potential use case for it in dvc when checking metadata), but it is clearly desirable when you will be giving your fs instance to a user or anyone else who might try to do something funky with it, but my feeling is that people don't seem to use fsspec like that a lot these days (at least not yet). Also this will create a bit of a complication by needing to check that flag in fs code, unless we find some kind of clever trick to do that. Or we just might be okay that not all filesystems comply with that for now (e.g. gitfs clearly will error out no matter what if you try to write, but some other fs might not check that flag until a maintainer cares enough to do that). If I will be implementing the first part of read_only/immutable, i'll definitely take a look if we could gracefully support this read-only mode along the way.