bug: dav-server integration mishandles WebDAV folder operations

[ngg]

Describe the bug

When using dav-server-opendalfs with an OpenDAL service backend, common WebDAV operations from Windows Explorer fail or return generic errors.

he integration uses DAV paths in comparisons without first converting them to the same normalized form OpenDAL uses internally. This can make path comparisons fail even though the paths refer to the same object.

Collection operations are also not always handled as OpenDAL directory-shaped paths with trailing slashes. This affects folder metadata, listing, creation, deletion, and Windows Explorer's new-folder flow, which creates a temporary folder and then renames it.

Some unsupported or conditional operations are also mapped to generic failures instead of appropriate WebDAV errors.

Steps to Reproduce

1. Run a WebDAV server using dav-server-opendalfs backed by an OpenDAL service.
2. Open the OpenDAL service-backed WebDAV path from Windows Explorer.
3. Try different file and folder operations, for example:
   • browse/list a directory
   • create a new folder
   • rename the newly-created folder
   • upload or create a file
   • rename, copy, or delete files
   • delete folders
4. Observe that some operations fail, especially folder operations and Windows Explorer's create-folder-then-rename workflow.

Expected Behavior

Windows Explorer should be able to perform normal supported WebDAV operations against an OpenDAL-backed path.

Path comparisons inside the WebDAV integration should use the same normalized path form as OpenDAL, folder operations should use directory-shaped paths consistently, slashless collection metadata requests should still resolve to the directory object, and unsupported operations should return appropriate WebDAV errors instead of generic failures.

Additional Context

This affects the integrations/dav-server crate. The problematic areas include path comparison, collection handling, empty-folder moves, capability checks for append/create-new writes, and mapping OpenDAL errors such as Unsupported, path-type errors, and conditional conflicts to suitable WebDAV filesystem errors.

Are you willing to submit a PR to fix this bug?

• Yes, I would like to submit a PR.

[dosubot]

Thanks for the detailed report, @ngg. I looked into the current integrations/dav-server code and can confirm the areas you've identified. Here's a summary of the specific issues I see in the current implementation:

1. Path normalization mismatch in fs_path()

The fs_path() method just does a UTF-8 conversion of the raw DavPath bytes without running normalize_path(). Meanwhile, OpendalStream normalizes the path for self-filtering [1]. This inconsistency means path comparisons elsewhere (e.g. in metadata(), rename()) use un-normalized DAV paths against OpenDAL's normalized internal paths.

2. Missing trailing slashes for collection operations

• metadata() passes the path as-is from DavPath [2] — if a client requests metadata for a collection without a trailing slash, OpenDAL may not resolve it as a directory.
• rename() uses as_rel_ospath() [3] which strips the leading / but doesn't ensure a trailing / for collections, so directory renames may fail.
• remove_dir() delegates directly to remove_file() [4] without ensuring the path has a trailing slash for OpenDAL's directory deletion semantics.

3. Overly coarse error mapping

The convert_error() function maps everything except AlreadyExists, IsSameFile, and NotFound to FsError::GeneralFailure. This means Unsupported (e.g. when rename isn't supported by the backend), conditional conflicts, and path-type errors all surface as generic failures to the WebDAV client instead of more meaningful HTTP status codes.

4. Rename logic for collections

The rename implementation [5] attempts to pre-delete the destination when from.is_collection() is true, but for empty-folder moves (like Windows Explorer's create-temp-folder-then-rename pattern), this may fail or be a no-op if the destination doesn't exist yet — and any failure from remove_file is silently ignored with let _ =.

Since you've indicated you'd like to submit a PR, these would be the key areas to address. A recently merged PR (#7876) already updated this crate to use opendal-core directly and refined imports, so you'll want to base your changes on the latest main.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.