[MC-164316] Resource pack update by a hash doesn't work

The bug

When specifying a resource pack URL and checksum / hash in the server.properties and the client detects that the checksum does not match for an existing resource pack, it fails deleting it, because the file is already being used by another process.

[20:58:22] [Client thread/WARN]: File \.minecraft\server-resource-packs\d31664486132157cf0f82534f1d1c66f75411418 had wrong hash (expected 6a0fc6c57023a7a47d9abc463090dcd28f3fa7aa, found 1b88a157a6edaa6d332a6fe65baa2fd73895ac9a).
[20:58:22] [Client thread/WARN]: Pack application failed: Hash check failure for file \.minecraft\server-resource-packs\d31664486132157cf0f82534f1d1c66f75411418, see log, deleting file \.minecraft\server-resource-packs\d31664486132157cf0f82534f1d1c66f75411418
[20:58:22] [Client thread/WARN]: Failed to delete file \.minecraft\server-resource-packs\d31664486132157cf0f82534f1d1c66f75411418: \.minecraft\server-resource-packs\d31664486132157cf0f82534f1d1c66f75411418: Der Prozess kann nicht auf die Datei zugreifen, da sie von einem anderen Prozess verwendet wird.

Code analysis

In the method clientPackSource.clearServerPack() only the reference to the UnopenedResourcePack is removed, but the pack is not closed before.

Linked issues

is duplicated by 2

MC-165927 Unable to update resource pack while on server Resolved

MC-252456 Failed to delete file, Download server resource pack Resolved

relates to 1

MC-251126 Server resource pack is not redownloaded when a hash mismatch is detected with the previously downloaded version Resolved

Comments 24

[Mod] violine1101 2019-10-22T21:01:15Z

Can you provide some more details, i.e., what are you trying to do, what exactly needs to be done to reproduce this issue, are you sure you don't have the resource pack open in the explorer, etc?

Foorcee 2019-10-23T11:33:14Z

I changed the resource package. However, the same URL is used. Just pass the new hash (checksum) of the file. The client then noticed that the hash does not match the local one. And want to re-download the resource package. The client could not delete the old one because it was already in use (Still loaded).

I hadn't opened the file or folder.

Foorcee 2019-10-23T11:39:57Z

Each time the player enters the server, a request will be sent to him that he should load the resource package. Along with the current hash of the file on the host

Foorcee 2019-10-25T12:04:52Z

I may have found the problem.
In the method clientPackSource.clearServerPack() only the reference to the UnopenedResourcePack is removed, but the pack is not closed before.

MrGazdag 2019-11-09T14:12:05Z

Can confirm.

14 more comments

MrGazdag 2019-11-10T10:21:07Z

I have made a Bukkit plugin that tests this which sends the resource pack with a command, and if the resource pack is already loaded by the client, it will not be able to unload it, Even if you send another server resource pack. This means the player would need to restart Minecraft to see the updated pack.

Noah Groß 2019-11-29T14:14:14Z

Can confirm. Did the same thing as @MrGazdag and noticed that mc was not closing the file even after unloading the rp. Client trying to delete the file causes a sharing violation on the filesystem.

marcono1234 2020-02-13T15:51:24Z

Even if deleting the outdated pack worked, would it then actually replace it? It appears ClientPacketListener.downloadCallback(CompletableFuture<?>) would simply send to the server that the download failed.

Tralomine 2020-05-04T00:48:16Z

can confirm for 20w18a

Nassim Jahnke 2020-06-17T16:19:24Z

Still with 1.16-pre8

Nicholas Nassar 2020-12-19T05:11:17Z

Unfortunately, this issue still exists in version 1.16.4. It seems like you can send the resource pack to the client twice to fix it, but this does cause it to load twice on clients no matter whether they experience this issue or not, which is very annoying.

Justice Almanzar 2021-02-01T18:13:59Z

This issue still exists in version 1.16.5

jamie 2021-02-02T22:22:12Z

this issue is annoying and the only way to avoid this is to use something like fabric (forge does not fix this) it has been a issue for so long and its stopping server progress (our network relies on this to function correctly) the amount of users i've had complain about this exact issue and i've told them not to use normal minecraft as its broken is kinda shameful

mojang please bump this to a higher priority bug as its been a bug through 3 major versions of Minecraft

Phoenix616 2021-02-03T12:50:52Z

@jamei there is a workaround for this: Simply append the URL of the pack with the hash of the pack e.g. https://example.com/mypack.zip#9q3pam2eimqp0 This will make the client treat that as a completely new pack and re-download it (as the URL changed) instead of testing the local pack and failing to refresh it. But to the web server itself offering the pack the URL will look the same as before as it ignored parameters after a "hashtag". (I currently use this method in my resourcepacks Spigot/Bungee/Velocity plugins to work around this issue)

The only downside for this is that old packs are going to stay in the player's server-resource-packs folder which isn't ideal if you have large packs that change often.

jamie 2021-02-11T18:33:20Z

this didnt work it actually now made it so its a incorrect URL im using a bungeecord plugin to manage texture packs on a per server basis (ForceResourcePacks) which kicks people for not accepting

Phoenix616 2021-02-11T19:52:58Z

@jamie I was referring to the Vanilla server resource packs functionality, not some plugin. (And if you mean my plugin then that functionality is already built-in to work around this bug)

MukiTanuki 2021-07-05T11:17:00Z

affects 1.17

SkytAsul 2021-08-15T16:05:06Z

@Phoenix616 this didn't work for me :/ I'm still getting

[18:02:46] [Downloader 5/WARN]: File C:\Users\skyta\AppData\Roaming\.minecraft\server-resource-packs\d66314ef3fa02917cc5979fbc10eee7a77970ede had wrong hash (expected A97B4069B1B40DB03B1695DE027F70FB652C6FA5, found ba837fc60da4ca4579b5d8f81cbd6edacfe8eecf).
[18:02:46] [Downloader 5/WARN]: Pack application failed: java.lang.RuntimeException: Hash check failure for file C:\Users\skyta\AppData\Roaming\.minecraft\server-resource-packs\d66314ef3fa02917cc5979fbc10eee7a77970ede, see log, deleting file C:\Users\skyta\AppData\Roaming\.minecraft\server-resource-packs\d66314ef3fa02917cc5979fbc10eee7a77970ede

Nathan Wolf 2021-08-16T19:34:27Z

I am having a similar issue, but it is not failing to delete the file, it just fails to apply the new pack. This seems to be new 1.17 behavior:

File /Users/nathan/Library/Application Support/minecraft/server-resource-packs/ff251496d074136489fa5136c71b99bc8dbd0fd8 had wrong hash (expected 642c3be6698603ee3c0d887ad8386e3d7aa1f7cd, found 73f7dd5236c76b45907932c38f1be8eb8a8ddac9).

Pack application failed: java.lang.RuntimeException: Hash check failure for file /Users/nathan/Library/Application Support/minecraft/server-resource-packs/ff251496d074136489fa5136c71b99bc8dbd0fd8, see log, deleting file /Users/nathan/Library/Application Support/minecraft/server-resource-packs/ff251496d074136489fa5136c71b99bc8dbd0fd8

I will get this every time I update my RP (in-place, same URL different hash).

The delete does work for me though, so if I immediately re-send the same URL and hash it works.

This is not ideal of course (will require plugin functionality to work without the player relogging), and this used to work fine pre-1.17.

Thank you for your attention, and I apologize for the insta-edit.

SyntheticDev 2022-07-02T15:08:42Z

Adding a comment to say that this issue still occurs in 1.19.
The workaround I have found is to send a different URL with the new hash to the client, this causes the old pack to be correctly deleted and the new one to be downloaded and applied correctly.

MrGazdag 2022-07-02T16:02:52Z

@SyntheticDev this workaround was posted earlier in this thread, you can just append the hash at the end of the url like this:

http://example.com/resourcepack.zip#ABCD1234

MrKinau 2022-09-03T18:56:37Z

Can confirm for 1.19.2

Medium Difficulty 2023-04-01T17:47:30Z

Can confirm in 1.19.3 and 1.19.4

MrKinau 2023-11-02T15:21:16Z

Can confirm 23w44a