Bug #19897
closed
FUSE should return a different error when attempting to create a file in a project
Added by Peter Amstutz over 1 year ago.
Updated over 1 year ago.
Release relationship:
Auto
Description
You cannot create a bare file in a Project in the FUSE mount (only in Collections). If you try, you will get I/O error. This is disorienting because I/O error usually means something very bad happened. This should be something else like:
EPERM "Operation not permitted"
ENOSYS "Function not implemented"
Internally it is actually throwing NoImplementedError so catching that exception generally and turning it into ENOSYS would make sense. However the particular function that tries to create a file in a project could throw EPERM since it is more precise semantics.
From discussion: let's go with ENOTSUP "Operation not supported (POSIX.1-2001)."
- Status changed from New to In Progress
- Description updated (diff)
- Status changed from In Progress to New
- Target version changed from 2023-02-01 sprint to Future
- Assigned To set to Peter Amstutz
- Release set to 59
- Target version deleted (
Future)
- Assigned To deleted (
Peter Amstutz)
- Description updated (diff)
- Target version set to To be scheduled
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."
- Target version changed from To be scheduled to Future
- Description updated (diff)
- Target version changed from Future to To be scheduled
- Target version changed from To be scheduled to 2023-02-01 sprint
- Assigned To set to Brett Smith
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.
- Status changed from New to In Progress
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.
- Status changed from In Progress to Resolved
Also available in: Atom
PDF