A user could select another local file with the same name as one that already
exists in completed storage. The upload would be allowed to start and only hit
an existing-file conflict late in the flow, which made the UI look like the
file was uploadable.
Reject duplicate sanitized names during upload creation so no staging record or
chunk transfer starts for a file that cannot be completed. Keep the completion
path non-replacing as a second guard by promoting through a no-overwrite file
creation path, with a hard-link fast path and copy fallback for custom temp
locations.
The browser now treats the server's duplicate-name conflict as a terminal row:
it disables the action, marks the item visually, and tells the user to rename
the file if they want to upload that copy.
Test Plan:
- just check
Refs: none
The browser upload flow was built around one selected file and one global
upload state. That made the existing chunk pool useful for a single file, but
users could not start several selected files at the same time.
Refactor the browser state into per-file upload items. Each selected file now
has its own upload record, completed-chunk set, abort controller, retry state,
progress row, and saved IndexedDB resume record. The picker accepts multiple
files, `Start all` and `Resume all` use a bounded file-level pool, and each file
keeps the existing bounded chunk pool. This keeps parallel uploads useful
without letting one large selection create unbounded request fan-out.
Keep the server API unchanged. Each file still receives a separate server upload
id, and server-side progress remains authoritative before any missing chunks are
scheduled. Terminal conflicts still stop the affected file without overwriting
completed data.
Update the user-facing markup, styles, project docs, and test checklist for the
multi-file scheduler. Add a server regression test that interleaves two uploads
and verifies the completed files contain exactly their own bytes.
Test Plan:
- just check
- git diff --check
A newly selected file has no server upload record yet, so the UI calls the
progress renderer with zero completed chunks and zero total chunks. Treating
that zero-total state as complete made the progress bar jump to 100% before
any upload had started.
Render zero-total progress as empty instead. Existing resumable uploads still
show their server-authoritative completed chunk percentage, and completed
non-empty uploads still render as full because their completed count equals a
non-zero total.
Test Plan:
- just static-check
- just test
- git diff --check
Completed uploads used to copy every staged chunk into a second file before
renaming the result into data/complete. That doubled write volume and required
peak disk space for both the chunk set and the final file.
Write each chunk directly into one private temp upload file at its final offset
instead. After a chunk write succeeds, record a tiny durable completion marker
for progress and resume scans. Completion now verifies the temp file length and
all markers, then renames the temp file into the completed upload directory.
Add UPL_TEMP_DIR and --temp-dir so operators can choose where upload metadata,
markers, and temp files live. The default remains data/staging, and docs call
out that the temp directory must be on the same filesystem as data/complete for
atomic promotion. The nginx example now aliases only the completed upload
directory, and the smoke test verifies that final-file alias.
This keeps the existing length-based validation model; it does not add per-chunk
hashing.
Test Plan:
- just check
- just nginx-smoke
- cargo clippy && cargo clippy --benches && cargo clippy --tests
- cargo +nightly fmt --all
- cargo clippy && cargo clippy --benches && cargo clippy --tests
Refs: none
Successful completion moved the assembled file into data/complete but left the
upload staging directory behind, including all chunk files. Remove the upload's
staging directory only after the final file has been renamed into place so
incomplete and failed uploads remain resumable.
A repeat complete request for that old upload id now returns 404 because the
temporary upload record has been retired with its chunks.
Test Plan:
- just check
Refs: none
Add clap-powered --bind, --static-dir, and --data-dir flags for human-run
server configuration. The merge order is now explicit: command-line arguments
win over UPL_* environment variables, which still fall back to the existing
repository-local defaults.
Document the new flags and allow just run to forward arguments to cargo so the
help text can be checked through the normal task runner.
Test Plan:
- just check
- cargo run -- --help
Refs: none
The previous page showed a static "Server online" pill even though it did not
track backend liveness. It also left the selected file in an uploadable state
after completion, which made it too easy to start the same file again and then
land in a saved record that could only fail with "complete file already
exists".
Remove the misleading server-status UI and make saved uploads describe their
next action. Records with every chunk uploaded now show a Finish action, stale
server records are cleared, and a terminal "complete file already exists"
response clears the saved browser progress instead of inviting another resume.
A successful completion also clears the active file selection so the primary
actions settle back to idle.
Test Plan:
- just check
Refs: none
Clarify that the manual scenarios remain useful for real browser and deployment
retests, and keep the nginx deployment retest item separate from the checksum
command example.
Test Plan:
- just check
Add focused regression coverage for validation rules called out in PLAN.md.
Chunk upload tests now prove that an otherwise valid upload rejects an
out-of-range chunk index through the HTTP API. Completion tests now prove that a
manually corrupted chunk file is not assembled into a final file.
Update TESTS.md so the reusable checklist reflects these automated proofs.
Test Plan:
- just check
- just nginx-smoke
Refs: PLAN.md validation checklist
Add the nginx deployment artifact from PLAN.md. The example config keeps upl
behind nginx, sets client_max_body_size to 64 MiB, disables request buffering for
chunk uploads, forwards standard proxy headers, and leaves explicit placeholders
for TLS certificates and access control before public exposure.
Add just nginx-smoke as a reusable Docker-based verification. The script starts
upl with a temporary data directory, runs nginx as a reverse proxy, uploads a
17 MiB file through nginx, restarts the Rust backend mid-upload, confirms server
progress survives the restart through the proxy, uploads the remaining chunk,
completes the upload, and compares SHA-256 hashes.
Document the production nginx shape, the local Docker smoke-test caveat, and the
manual deployment retest scenario in TESTS.md.
Test Plan:
- bash -n scripts/nginx-smoke.sh
- just check
- just nginx-smoke
Refs: PLAN.md milestone 9
Replace the placeholder browser script with the PLAN.md upload flow. The static
UI now creates upload records, slices the selected file into fixed-size chunks,
uploads missing chunks with a concurrency pool of three workers, retries failed
chunks with exponential backoff, pauses via AbortController, and completes the
upload once the server has accepted every chunk.
Persist pending upload records in IndexedDB and render them in the page so a
reload can resume from server-authoritative progress. When the File System
Access API is available, the app stores a file handle and asks for read
permission during resume; when it is unavailable or permission is denied, the
same pending record resumes after the user reselects the matching file. Browser
state is helpful but not trusted: every resume starts by querying the server for
completed chunks.
Add a JavaScript syntax check to the justfile, update the static-page test and
documentation, and extend TESTS.md with the manual resume scenarios that still
need real-browser repetition.
Test Plan:
- just check
- UPL_BIND=127.0.0.1:39123 UPL_DATA_DIR=$(mktemp -d) cargo run
- curl -fsS http://127.0.0.1:39123/healthz
- curl -fsS http://127.0.0.1:39123/ | rg "Choose file|Pending uploads|app.js"
- firefox --headless --screenshot /tmp/upl-page.png http://127.0.0.1:39123/
Refs: PLAN.md milestones 5, 6, and 7
Implement POST /api/uploads/{id}/complete. The storage layer now reloads upload
metadata, verifies that every expected chunk exists with the exact expected
length, concatenates chunks in order into a temporary final file, flushes it,
and renames it into data/complete only after assembly succeeds.
The endpoint preserves staging data after completion, rejects incomplete uploads
with a conflict response, and refuses to overwrite an existing completed file.
This keeps failed or duplicate completion attempts explicit rather than silently
clobbering local files.
Extend the model, router, documentation, and test checklist for completion
responses and add integration coverage for successful assembly, incomplete
uploads, staging preservation, and duplicate completion conflicts.
Test Plan:
- just check
Refs: PLAN.md milestone 8
Add the chunk upload and progress APIs from PLAN.md. PUT
/api/uploads/{id}/chunks/{index} now accepts raw octet-stream bodies, validates
unknown upload ids, out-of-range chunk indexes, and exact chunk lengths, then
writes through a temporary .part.tmp path before renaming the completed chunk
into place. Re-uploading an already-complete chunk is idempotent when the
existing file length matches the expected length.
GET /api/uploads/{id} now reports server-authoritative progress by scanning the
chunk directory and only counting chunk files whose lengths match metadata. The
router also raises Axum's request body limit to 64 MiB so the planned 16 MiB
chunks can reach the handler, matching the nginx deployment guidance.
Document the chunk storage responsibility and extend the reusable test checklist
with the new progress and validation coverage.
Test Plan:
- just check
Refs: PLAN.md milestones 3 and 4
Add the first upload API endpoint from PLAN.md. POST /api/uploads now
validates the requested file name, generates a server-owned upload id, creates
the staging and complete directory layout, and writes durable meta.json before
returning chunk scheduling details to the browser.
Keep filesystem layout knowledge in storage.rs so later chunk upload and
completion work can reuse the same boundary. API handlers translate storage
errors into JSON HTTP responses without leaking layout details into the router.
Document the new modules and UPL_DATA_DIR configuration, and extend TESTS.md
with the automated creation coverage.
Test Plan:
- just check
Refs: PLAN.md milestone 2
Introduce the first PLAN.md milestone: replace the hello-world binary with
an Axum server that binds to localhost by default, exposes a health endpoint,
and serves the static browser UI from the repository's static directory. The
router is available through the library crate so integration tests can exercise
server behavior without opening a network listener.
Add a justfile for routine validation and document the initial project shape,
configuration knobs, and reusable test checklist. The rustfmt config now uses
only stable options so the new formatting recipe runs without nightly warnings.
The upload API and resumable chunk behavior are intentionally left for later
milestones; the UI currently handles file selection only.
Test Plan:
- just check
Refs: PLAN.md milestone 1
Document the minimal design for a personal large-file upload app that can
resume after browser, network, or server interruptions. The plan keeps the
first version intentionally small: one Rust server, one static browser UI,
filesystem-backed upload metadata, raw chunk uploads, and no database or
third-party resumable upload protocol.
The deployment notes include nginx as the external TLS and access-control
layer, with the Rust server bound behind it and upload-specific proxy settings
called out.
Test Plan:
- git diff --cached --check
Refs: user request
ddidderr
