DioxusLabs / DioxusLabs/dioxus

File input directory type does not keep directory structure for files() and subsequently drops duplicates

Open
#3,136 2 comments 0 reactions 0 assignees View on GitHub
bug
Dominant language
Rust
Stars
39.1k
Forks
1.9k
Avg merge
4d 10h
Merged PRs (30d)
4

Description

**Problem**

Using a directory / webkitdirectory file input to upload a directory, and then looping over the files() results, 2 things are broken:
1. there is no folder structure with the filenames to identify where they came from per https://developer.mozilla.org/en-US/docs/Web/API/HTMLInputElement/webkitdirectory#understanding_the_results
2. because of 1, if there is a duplicate filename in another directory, the names collide and only one remains

**Steps To Reproduce**

```rust
input {
type: "file",
multiple: true,
directory: true,
onchange: move |evt| {
if let Some(file_engine) = evt.files() {
for filename in file_engine.files() {
log::warn!("filename {filename}");
}
}
},
}
```

**Expected behavior**

If you upload a folder "a", with structure like:
```
a/1.txt
a/o.txt
a/b/1.txt
a/b/2.txt
```

You will only see:
```
1.txt
o.txt
2.txt
```

Which has lost the second 1.txt, because it also lost the subdir "b" from the file paths.

Instead I would like to see:
```
a/1.txt
a/o.txt
a/b/1.txt
a/b/2.txt
```

Note that the initial "a/" is required, because a folder was uploaded, not simply files inside that folder!

**Environment:**
- Dioxus version: main
- App platform: web -- but probably applicable to all

**Questionnaire**

I'm interested in fixing this myself but don't know where to start

Contributor guide

No contributing guide indexed for this repository

Research direction

Start by tracing the web file-input path from the onchange handler through evt.files() and file_engine.files(), then compare it with the browser's webkitdirectory results described in the issue. Done means returned names retain the uploaded root and subdirectories, including both a/1.txt and a/b/1.txt, with no duplicate dropped; add or run coverage for this case.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
frontend, web-dev
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
48/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.