Useless download count tracking for files without a download limit #178

New Issue

michael · 2026-01-19T18:29:18Z

michael commented

2026-01-19 18:29:18 +00:00

Originally created by @JustAnotherArchivist on GitHub.

This is essentially an extension of #362, but I wanted to put this up for discussion first as it's not as clear-cut.

There is currently no mechanism for changing the download limit for a file short of manually manipulating the metadata file. For that reason, it's useless in my eyes to track the download count at all on files that don't have a download limit set as it will never be used. The main issue with that is that these needless writes may incur costs for the operator depending on the storage backend and traffic volume, e.g. when using AWS S3 (operation cost) or Wasabi S3 (minimum retention).

I suppose the key questions are: is there any intention to ever add support for changing the MaxDownloads after upload? If not, is there any other reason for tracking the download count on files without a limit?

(I'll happily provide a PR if the answer to both questions is no.)

Originally created by @JustAnotherArchivist on GitHub. This is essentially an extension of #362, but I wanted to put this up for discussion first as it's not as clear-cut. There is currently no mechanism for changing the download limit for a file short of manually manipulating the metadata file. For that reason, it's useless in my eyes to track the download count at all on files that don't have a download limit set as it will never be used. The main issue with that is that these needless writes may incur costs for the operator depending on the storage backend and traffic volume, e.g. when using AWS S3 (operation cost) or Wasabi S3 (minimum retention). I suppose the key questions are: is there any intention to ever add support for changing the `MaxDownloads` after upload? If not, is there any other reason for tracking the download count on files without a limit? (I'll happily provide a PR if the answer to both questions is no.)

michael closed this issue

2026-01-19 18:29:18 +00:00

michael commented

2026-01-19 18:29:19 +00:00

@paolafrancesca commented on GitHub:

I'm fine without being able to change the MaxDownloads, mostly because it was never a feature and nobody requested it (so, it's not a missing feature ;)), and to introduce it would require some logic for identifying the owner of the upload that would be allowed to change the value: that's far from straightforward.

If I got right what your proposal is, it would be just a matter of checking metadata.MaxDownloads != -1 condition as well in the if that you just refactored. Am I correct?

@stefanbenten what do you think?

@paolafrancesca commented on GitHub: I'm fine without being able to change the `MaxDownloads`, mostly because it was never a feature and nobody requested it (so, it's not a missing feature ;)), and to introduce it would require some logic for identifying the owner of the upload that would be allowed to change the value: that's far from straightforward. If I got right what your proposal is, it would be just a matter of checking `metadata.MaxDownloads != -1` condition as well in the `if` that you just refactored. Am I correct? @stefanbenten what do you think?

michael commented

2026-01-19 18:29:19 +00:00

@JustAnotherArchivist commented on GitHub:

it would require some logic for identifying the owner of the upload that would be allowed to change the value

I suppose that could reuse the deletion token, so e.g. a PUT request against that URL with the new MaxDownloads value in a header, query, or body. But yeah, considering nobody asked for it in 6.5 years, it's probably not worth implementing.

If I got right what your proposal is, it would be just a matter of checking metadata.MaxDownloads != -1 condition as well in the if that you just refactored. Am I correct?

Yes, that's correct.

@JustAnotherArchivist commented on GitHub: > it would require some logic for identifying the owner of the upload that would be allowed to change the value I suppose that could reuse the deletion token, so e.g. a PUT request against that URL with the new `MaxDownloads` value in a header, query, or body. But yeah, considering nobody asked for it in 6.5 years, it's probably not worth implementing. > If I got right what your proposal is, it would be just a matter of checking `metadata.MaxDownloads != -1` condition as well in the if that you just refactored. Am I correct? Yes, that's correct.

michael commented

2026-01-19 18:29:19 +00:00

@stefanbenten commented on GitHub:

I think that is a totally fine approach!
Much appreciate the improvement proposal! 👍

@stefanbenten commented on GitHub: I think that is a totally fine approach! Much appreciate the improvement proposal! :+1:

michael referenced this issue

2026-01-19 18:29:38 +00:00

Append Max-Downloads and Max-Days on response headers #259

Sign in to join this conversation.