fix: align PROPFIND/PROPPATCH metadata keys with Graph Metadata API#693
Open
flash7777 wants to merge 4 commits into
Open
fix: align PROPFIND/PROPPATCH metadata keys with Graph Metadata API#693flash7777 wants to merge 4 commits into
flash7777 wants to merge 4 commits into
Conversation
added 4 commits
June 18, 2026 21:45
The Graph Metadata API stores arbitrary metadata using short keys (e.g. "oy.fileReference"), but PROPFIND and PROPPATCH used full namespace URI keys (e.g. "http://owncloud.org/ns/oy.fileReference"). This mismatch meant properties set via the Metadata API could never be read via PROPFIND, and vice versa. Changes: - requiresExplicitFetching: allow all oc: namespace properties to trigger metadata fetching (was hardcoded to known properties only) - metadataKeyOf: use local name directly for oc: namespace instead of prefixing with the full namespace URI - proppatch: same key format change for consistency This enables reading custom metadata (set via Graph API) in standard WebDAV PROPFIND responses, e.g.: <oc:oy.fileReference/> → returns "11.03"
The allprop handler only output known metadata keys (tags, audio, location, image, photo). Arbitrary custom metadata set via the Graph Metadata API was silently omitted. Now all non-empty custom metadata keys are included in the allprop response.
…g 404 The oc: namespace default case in mdToPropResponse immediately returned 404 for unknown properties without checking ArbitraryMetadata. Only non-oc/non-DAV namespaces had the metadata lookup. Now unknown oc: properties are looked up in ArbitraryMetadata before returning 404.
- Walker: ListContainer with ArbitraryMetadataKeys: ["*"] so search indexing receives custom metadata (e.g. oy.fileReference) - propfind: oc: namespace default looks up ArbitraryMetadata before 404
3 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
The Graph Metadata API (
/graph/v1beta1/drives/{driveID}/items/{itemID}/metadata) stores arbitrary metadata using short keys (e.g.oy.fileReference), which are persisted as xattrs likeuser.oc.md.oy.fileReference.However, PROPFIND and PROPPATCH use full namespace URI keys (e.g.
http://owncloud.org/ns/oy.fileReference), causing a key mismatch:user.oc.md.*) but with incompatible key formatsChanges
propfind.go:requiresExplicitFetching: returntruefor alloc:namespace properties (wasfalsefor unknown ones, preventing metadata fetch entirely)metadataKeyOf: usen.Localdirectly foroc:namespace instead offmt.Sprintf("%s/%s", n.Space, n.Local)— matches how the Graph API stores keysproppatch.go:oc:namespace, full URI for other namespacesBefore / After
Before: 404 Not Found (property not fetched, key mismatch)
After: 200 OK with value
11.03Impact