-
Notifications
You must be signed in to change notification settings - Fork 542
Description
I'm currently trying to implement a new afero FS, and one thing which is hitting me is the relatively limited selection of afero filesystem error codes.
Afero currently defines the following:
ErrFileClosed = errors.New("File is closed")
ErrOutOfRange = errors.New("out of range")
ErrTooLarge = errors.New("too large")
ErrFileNotFound = os.ErrNotExist
ErrFileExists = os.ErrExist
ErrDestinationExists = os.ErrExist
Within my mental model of it though, it seems like this should be a somewhat wider set of codes so that at the very least when using afero the first thing you receive back is an "afero" branded error, rather then some other type - even if it's just a mapping to a golang built in.
From the list above then it feels like we're missing a couple which would make logical sense here - i.e. ErrPermission
and ErrDeadlineExceeded
(which is rendered as i/o timeout
, which is at least adequate for a good number of possible non-specific failures you might use an afero filesystem for).
There's also some which are syscall specific but probably should have an afero representation i.e. syscall.ENOTDIR
has a lot of obvious use, but the syscall library is platform specific whereas afero potentially isn't.
Finally there's a general need for some type of "error in the filesystem" return. Depending what you're doing a lot can happen, and within an implementation the main thing I know is that the user knows they're using Afero since they must've instantiated it at some point: so if my backing logic falls apart from me say, mid-Readdir call, what I want to kick back is some kind of general error that says "hey, this isn't a you problem, it's a me problem but everything is also broken" (i.e. ErrFilesystem
or something.)