OpenDAL Error Mapping in the dav-server Integration#

The dav-server integration bridges OpenDAL's rich error model to the limited three-value error type that the dav_server crate exposes to WebDAV clients. The entire mapping lives in a single function, convert_error, in integrations/dav-server/src/utils.rs.

The Mapping Function#

convert_error takes an opendal::Error and returns a dav_server::fs::FsError:

The catch-all _ arm collapses all other OpenDAL error kinds — including PermissionDenied, Unauthorized, InvalidArgument, RateLimited, and others — into GeneralFailure 1. This is a deliberate trade-off: the WebDAV protocol surface provides no finer-grained distinctions for most of these conditions, so surfacing them as GeneralFailure is the safest option for client compatibility.

Where convert_error Is Called#

convert_error is imported and used consistently across all three operational layers of the integration:

• fs.rs — Filesystem operations: All top-level WebDAV methods (read_dir, metadata, create_dir, remove_file, rename, copy) call convert_error when mapping OpenDAL results to FsError. For example, metadata uses it at line 114, read_dir at line 100, and rename/copy at lines 188, 203.
• file.rs — File open/stat operations: OpendalFile::open calls convert_error when acquiring a reader or writer from OpenDAL. The DavFile::metadata method also routes through it 2.
• dir.rs: Directory stream construction calls convert_error when the underlying lister fails 3.

Important Nuances#

• fs_path conversion errors bypass convert_error and directly return FsError::GeneralFailure — a non-OpenDAL error path 4.
• create_dir contains additional pre-flight checks: Parent-existence and duplicate-directory checks issue explicit FsError::NotFound and FsError::Exists values before any OpenDAL call, not via convert_error 5. This enforces RFC 2518 §8.3.1 semantics directly in the integration layer.
• I/O errors inside file reads/writes/seeks are also mapped directly to FsError::GeneralFailure without going through convert_error, because they originate from the AsyncRead/AsyncWrite trait layer, not from OpenDAL Error values 6.

Extending the Mapping#

If a new OpenDAL ErrorKind needs a distinct WebDAV response (e.g., mapping PermissionDenied to a future FsError::Forbidden), add a new arm to the match in utils.rs. All call sites automatically benefit without changes elsewhere.