Skip to content

fix(services/dbfs): make listed entry paths relative to the root - #8083

Merged
erickguan merged 1 commit into
apache:mainfrom
PDGGK:fix-dbfs-lister-rel-path
Aug 15, 2026
Merged

fix(services/dbfs): make listed entry paths relative to the root#8083
erickguan merged 1 commit into
apache:mainfrom
PDGGK:fix-dbfs-lister-rel-path

Conversation

@PDGGK

@PDGGK PDGGK commented Aug 15, 2026

Copy link
Copy Markdown
Contributor

Which issue does this PR close?

None. This is the second half of #8079, kept separate because it changes what users see rather than what goes on the wire.

Rationale for this change

The lister emits status.path straight from the response:

for status in decoded_response.files {
    let entry: oio::Entry = match status.is_dir {
        true => {
            let normalized_path = format!("{}/", status.path);
            ...
            oio::Entry::new(&normalized_path, meta)
        }
        false => {
            ...
            oio::Entry::new(&status.path, meta)
        }
    };

DbfsCore::list sends the prefix as build_rooted_abs_path(&self.root, path), and DBFS echoes absolute paths under that prefix. So every entry comes back carrying the root and a leading slash — /data/dir/f.txt where the entry contract asks for dir/f.txt. Even at the default root the leading slash is wrong.

alluxio is the exact analogue in this tree — same API shape, appends / for directories, then relativises:

let path = if file_info.folder { format!("{path}/") } else { path };
ctx.entries.push_back(Entry::new(
    &build_rel_path(&self.core.root, &path),
    file_info.try_into()?,
));

Every other HTTP service lister does the same; dbfs is the only one that omits it. Nothing downstream repairs it either — oio::Entry::with only rewrites the empty string to "/".

What changes are included in this PR?

build_rel_path applied once per entry, hoisted above the match because both arms need it. Three lines.

Tests

None — the change makes this lister do what alluxio and the rest already do, and there is no directory under .github/services for dbfs, so nothing exercises the listing path either way.

cargo build, cargo clippy -p opendal-service-dbfs --all-targets (zero warnings) and cargo fmt --all -- --check are clean.

Are there any user-facing changes?

Yes: listed entries are relative to the operator root, as the entry contract requires, instead of carrying the root and a leading slash.

The lister emits status.path straight from the response. DbfsCore::list
sends the prefix as build_rooted_abs_path(&self.root, path), and DBFS
echoes absolute paths under that prefix, so every entry comes back
carrying the root and a leading slash -- "/data/dir/f.txt" where the
contract asks for "dir/f.txt".

alluxio is the exact analogue in this tree: same API shape, appends "/"
for directories, and then calls build_rel_path. It is the one every
other HTTP service lister uses; dbfs is the only omission.

Nothing downstream repairs it. oio::Entry::with only rewrites the empty
string to "/".

Hoisted rather than called twice because rustfmt splits the line either
way, so this is the smaller of the two shapes.
@PDGGK
PDGGK requested a review from Xuanwo as a code owner August 15, 2026 07:45
@dosubot dosubot Bot added size:XS This PR changes 0-9 lines, ignoring generated files. releases-note/fix The PR fixes a bug or has a title that begins with "fix" labels Aug 15, 2026
@dosubot dosubot Bot added the lgtm This PR has been approved by a maintainer label Aug 15, 2026
@erickguan
erickguan merged commit 8a520de into apache:main Aug 15, 2026
110 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

lgtm This PR has been approved by a maintainer releases-note/fix The PR fixes a bug or has a title that begins with "fix" size:XS This PR changes 0-9 lines, ignoring generated files.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants