With a download limit of 1, downloading one file of a share with
several files deleted the share and the files not yet downloaded.
ShareService::recordDownload() ran at the end of every download
request, one file or the ZIP alike, and deleted the share as soon as
download_count reached max_downloads. It has worked that way since
the first commit.
- One recipient's visit is one download. The first file or ZIP a
session downloads is counted when it starts, in one conditional
UPDATE that also checks the limit, so two recipients starting at
once can't both take the last download. The session remembers the
time, and for ShareService::DOWNLOAD_WINDOW_MINUTES (60) it may
start more downloads of the share without counting them, even once
the limit is reached. The claim happens in the controller before
streaming, because the session is saved before the body is sent,
and after the share key is resolved, so a request without the key
uses nothing.
- A share at its limit is closed to everyone else at once. The hourly
cleanup deletes it 24 hours after shares.last_downloaded_at (new
column), since a ZIP opens each file only when it reaches it and a
large download can outlast the hour.
- The download page of a limited share says how many downloads are
left, switches to "You have 1 hour" on the first press (Alpine, as
a download link does not render the page again), and shows the time
left on the next visit.
- The admin dashboard shows "2 of 3 downloads", marks shares at their
limit "Download limit reached" and leaves them out of Active Shares.
- Tests: the regression (3 files, limit 1: every file and the ZIP
download, counted once), another recipient, the end of the hour,
the last download going to one of two recipients, requests refused
before streaming, unlimited shares, the page notes in PHP and in
Chromium, the dashboard, and the cleanup at 23 and 25 hours. The
tests of recordDownload() and of the instant deletion are gone.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
