Arvados

Before we put this on a sprint I feel like we should really pick which error we're going with.

Personally I would vote for ENOSYS since I think "the system doesn't support this" more accurately describes the problem than "you don't have permission to do this."

      ENOTSUP         Operation not supported (POSIX.1-2001).

      EOPNOTSUPP      Operation not supported on socket (POSIX.1-2001).

                       (ENOTSUP and EOPNOTSUPP have the same value on Linux, but according to POSIX.1 these error values should be distinct.)

The thing that actually matters is what error message is printed by other programs, e.g. the shell, when you try to do something. Which probably comes from strerror(3)

19897-fuse-enotsup @ d9cb58fdfa203eee880dba91a239a1f0edf97422 - developer-run-tests: #3468

When I started working on this, I expected that I would be doing something similar for the other "top level directories" that arv-mount provides, and I wrote tests accordingly. That turned out not to happen: because those mounts are generally not writable at all, the Operations class returns EPERM for any attempt to write them.

IMO it would be more consistent to return ENOTSUP for all attempted writes like this. It's not like there's some Arvados permission you can grant yourself that will magically make the write work, and I think that's most people's model of what EPERM means. But that's a bigger change that's out of scope for this ticket. So I committed my tests currently asserting that the operations return EPERM, with a note that IMO ENOTSUP would be better.

Brett Smith wrote in #note-17:

19897-fuse-enotsup @ d9cb58fdfa203eee880dba91a239a1f0edf97422 - developer-run-tests: #3468

When I started working on this, I expected that I would be doing something similar for the other "top level directories" that arv-mount provides, and I wrote tests accordingly. That turned out not to happen: because those mounts are generally not writable at all, the Operations class returns EPERM for any attempt to write them.

IMO it would be more consistent to return ENOTSUP for all attempted writes like this. It's not like there's some Arvados permission you can grant yourself that will magically make the write work, and I think that's most people's model of what EPERM means. But that's a bigger change that's out of scope for this ticket. So I committed my tests currently asserting that the operations return EPERM, with a note that IMO ENOTSUP would be better.

This LGTM.