Comments (4)
from fuse.
There is a large inconsistency with some error codes being defined in the fuse
package, where each code listed above is not defined here. This would also lead one to believe they are not being correctly utilized within the package (giving no need to define them, previously.)
Codes that ARE defined include:
fuse.EIO
fuse.ENOSYS
fuse.EEXIST
fuse.ENOENT
fuse.ENOATTR
fuse.ENOTDIR
fuse.ENOTEMPTY
I had noticed EINVAL
used in many incorrect places, which would be resolved by correctly implementing each of the above error codes where they should be expected, as described in the kernel man pages. The incorrect usage has caused me (and others) various troubleshooting headaches, as anything we created using this package performed erratically when running filesystem testing tools.
from fuse.
I don't know what you mean by "incorrect usage" -- these constants are there for your use, not for use by the package itself. Is the package itself using them somewhere incorrectly?
In any case, I think this is the relevant comment:
These may be treated specially by Connection.Reply.
The package only defines those that it needs to behave specially for. Ideally it would be consistent and define all or none of them, but I don't see how that's possible given that the set of error codes may differ across platforms.
from fuse.
these constants are there for your use
Here are just three (of many) examples of where we might need these constants to correctly implement a filesystem:
- Responding to
SetXattr
on bad names (missing or incorrect prefix)
The Linux man pages state under ERRORS
for setxattr(2)
that one must reply with ENOTSUP
(which is not semantically the same as fuse.ENOSYS
) when attempting to set an attribute with a prefix not defined in the specification. You can test this on existing filesystems (to see how they respond) with the setfattr
tool found in the attr
system package.
- Responding to
ReleaseFileHandle
on already closed or stale file handle
The Linux man pages state under ERRORS
for close(2)
and close(3)
that one must reply with EBADF
when the file handle passed in " isn't a valid file descriptor. "
- Responding to
OpenFile
on a directory
The Linux man pages state under ERRORS
for open(2)
that one must reply with EISDIR
in one of the multiple conditions. Here is a quote of the relevant passage from the pages included in Ubuntu 18.04 for reference:
EISDIR pathname refers to a directory and the access requested
involved writing (that is, O_WRONLY or O_RDWR is set).
EISDIR pathname refers to an existing directory, O_TMPFILE and one of
O_WRONLY or O_RDWR were specified in flags, but this kernel
version does not provide the O_TMPFILE functionality.
Ideally it would be consistent and define all or none of them, but I don't see how that's possible given that the set of error codes may differ across platforms.
As per conditional compilation
# +build linux darwin
// ... platform specific constants
If we disagree on the motive for implementing these constants, then I'll gladly concede using these constants for using the ones in the syscall
package.
from fuse.
Related Issues (20)
- No debug information for RenameOp HOT 1
- InMessage initialization is in a wrong place
- WriteFile does not work in memfs as it is invoked py PID 0 HOT 5
- Operations frequently canceled when accessing a `gcsfuse` mount with a Go application HOT 2
- Writing offset is not in sequential order HOT 2
- alpine getdents64 lost direntries HOT 3
- Proposal to avoid memory copies between jacobsa FUSE library and application code HOT 4
- Add Mount Config to select use OsxFuse or Fuse-T HOT 2
- Support fuse copy_file_range? HOT 1
- Supporting Fuse Passthrough HOT 3
- How to run in Docker container? HOT 2
- Shared mmap mapping results in -EACCES or -ENODEV HOT 3
- support open with openflag? HOT 3
- Not compatible to fuse3 HOT 1
- why the pagesize is always 4096? HOT 3
- Would you tell me fuseops error messages in detail ? HOT 1
- Compilation error on FreeBSD
- Shift enforced default permissions to an option. HOT 2
- Running tests sometimes hangs at the FUSE level HOT 6
- Switch from Travis to GitHub Actions HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from fuse.