mirror of
https://github.com/filebrowser/filebrowser.git
synced 2026-07-29 10:40:44 +00:00
No description
0b925cbca9
A TUS PATCH rejected before its body was read left the client still streaming a chunk. net/http gives up draining an unread request body after 256KiB and then closes the connection, so the status we replied with was lost and the browser saw a bare transport error instead. The client could not tell a conflict from a network fault, retried blindly, and the upload stalled after the first chunk — while curl, which reads the response as it writes, still reported the status and appeared to work. Drain what is left of a rejected chunk so the answer arrives on a connection that stays usable. The explicit r.Body.Close() had to go with it: it ran before the drain, and the server closes the request body itself once the handler returns. Pressing Upload awaited a recursive listing of the whole destination subtree before a single byte was sent, with no sign that anything was happening. On a large destination that reads as a dead button, and the walk kept running after the client gave up, then reported the failed write as a 500. A flat upload can only collide with a direct child of the destination, so walk recursively only for folder uploads, stop the walk once the request is done, and show the action as busy while the destination is checked. Along the way: a failed upload was credited as fully sent, so the progress bar reported 100% when nothing had been written; the progress timer was recreated without clearing the previous one; and the chunk size field threw on a value with no unit and raced its own debounce on submit, so it appeared to refuse every change. Fixes #6006 Refs #5987 |
||
|---|---|---|
| .claude | ||
| .github | ||
| auth | ||
| branding | ||
| cmd | ||
| diskcache | ||
| docker | ||
| errors | ||
| files | ||
| fileutils | ||
| frontend | ||
| http | ||
| img | ||
| rules | ||
| runner | ||
| search | ||
| settings | ||
| share | ||
| storage | ||
| users | ||
| version | ||
| www | ||
| .dockerignore | ||
| .gitignore | ||
| .golangci.yml | ||
| .goreleaser.yml | ||
| .versionrc | ||
| CHANGELOG.md | ||
| CODE-OF-CONDUCT.md | ||
| compose.yaml | ||
| CONTRIBUTING.md | ||
| Dockerfile | ||
| Dockerfile.s6 | ||
| go.mod | ||
| go.sum | ||
| LICENSE | ||
| main.go | ||
| README.md | ||
| renovate.json | ||
| SECURITY.md | ||
| Taskfile.yml | ||
| transifex.yml | ||
File Browser provides a file managing interface within a specified directory and it can be used to upload, delete, preview and edit your files. It is a create-your-own-cloud-kind of software where you can just install it on your server, direct it to a path and access your files through a nice web interface.
Documentation
Documentation on how to install, configure, and contribute to this project is hosted at filebrowser.org.
Project Status
This project is a finished product which fulfills its goal: be a single binary web File Browser which can be run by anyone anywhere. That means that File Browser is currently on maintenance-only mode. Therefore, please note the following:
- It can take a while until someone gets back to you. Please be patient.
- Issues are meant to track bugs. Unrelated issues will be converted into discussions.
- The priority is triaging issues, addressing security issues and reviewing pull requests meant to solve bugs.
- No new features are planned. Pull requests for new features will not be reviewed.
Please read @hacdias' personal reflection on the project status.
Contributing
Contributions are always welcome. To start contributing to this project, read our guidelines first.
License
Apache License 2.0 © File Browser Contributors