Do not touch hash-designated files which already exist at the destination storage

[Michal Krupa]

It seems a little silly that, even though local file copies are used to prevent needing to fetch files from remote destinations, files still get replaced even when they already exist.

In example, a remote storage implementation like S3 gets queried for the file, the file gets removed, and then replaced. With the boto3 library, this means touching the file initially (HEAD), a second request to DELETE the file, and yet a third to PUT the new file. Since filenames for hashed files are computed based on the contents of the files, this seems like an unnecessary 3 requests for every time static assets get processed.

Since a matching hash provides file integrity verification, I propose that the logic for copying hash-designated files be skipped all together.

PR Available here - ​https://github.com/django/django/pull/8496

[Tim Graham]

Is this a duplicate of or related to #28055? There are failing tests with the current PR.

[Michal Krupa]

Replying to Tim Graham:

Is this a duplicate of or related to #28055? There are failing tests with the current PR.

Ah yes I see the failed test results, jobs were still running when this ticket was opened. I will re-work the submission - thanks for the response!

[Tim Graham]

Tentatively accepting, though it's not certain that this can be fixed.