DioxusLabs / DioxusLabs/dioxus
File input directory type does not keep directory structure for files() and subsequently drops duplicates
- 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