Project

General

Profile

Actions

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 about 1 year ago.

Status:
Resolved
Priority:
Normal
Assigned To:
Category:
-
Target version:
Story points:
0.5
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)."


Subtasks 1 (0 open1 closed)

Task #19950: Review 19897-fuse-enotsupResolvedPeter Amstutz01/30/2023Actions
Actions #1

Updated by Peter Amstutz over 1 year ago

  • Status changed from New to In Progress
Actions #2

Updated by Peter Amstutz over 1 year ago

  • Description updated (diff)
Actions #3

Updated by Peter Amstutz over 1 year ago

  • Status changed from In Progress to New
Actions #4

Updated by Peter Amstutz over 1 year ago

  • Target version changed from 2023-02-01 sprint to Future
Actions #5

Updated by Peter Amstutz about 1 year ago

  • Assigned To set to Peter Amstutz
Actions #6

Updated by Peter Amstutz about 1 year ago

  • Story points set to 0.5
Actions #7

Updated by Peter Amstutz about 1 year ago

  • Release set to 59
  • Target version deleted (Future)
  • Assigned To deleted (Peter Amstutz)
Actions #8

Updated by Peter Amstutz about 1 year ago

  • Description updated (diff)
Actions #9

Updated by Peter Amstutz about 1 year ago

  • Target version set to To be scheduled
Actions #10

Updated by Brett Smith about 1 year ago

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."

Actions #11

Updated by Peter Amstutz about 1 year ago

  • Target version changed from To be scheduled to Future
Actions #12

Updated by Peter Amstutz about 1 year ago

  • Description updated (diff)
Actions #13

Updated by Peter Amstutz about 1 year ago

  • Target version changed from Future to To be scheduled
Actions #14

Updated by Peter Amstutz about 1 year ago

  • Target version changed from To be scheduled to 2023-02-01 sprint
Actions #15

Updated by Peter Amstutz about 1 year ago

  • Assigned To set to Brett Smith
Actions #16

Updated by Peter Amstutz about 1 year ago

      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)

Actions #17

Updated by Brett Smith about 1 year ago

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.

Actions #18

Updated by Brett Smith about 1 year ago

  • Status changed from New to In Progress
Actions #19

Updated by Peter Amstutz about 1 year ago

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.

Actions #20

Updated by Brett Smith about 1 year ago

  • Status changed from In Progress to Resolved
Actions #21

Updated by Peter Amstutz about 1 year ago

  • Release set to 57
Actions

Also available in: Atom PDF