NullPointerException at ExternalResourceMetaData.getSha1() at SourceRemapper

Minecraft version: any (especially 1.16.5 & 1.17.x)
Loom: from 0.5 to 0.9
Java: Oracle JDK 16.0.1 or AdoptOpenJDK 16.0.1.9
Gradle: 7.0.2 Binary from wrapper

build.gradle: Ubuntu Pastebin
settings.gradle:

pluginManagement {
    repositories {
        maven {
            name = 'Fabric'
            url = 'https://maven.fabricmc.net/'
        }
        gradlePluginPortal()
    }
}

buildscript.dependencies {
    classpath 'net.fabricmc:tiny-remapper:0.4.2'
}

StackTrace: Ubuntu Pastebin

I’ve tried in multiple devices, but I cannot understand why it crashes.
This repo also have this bug: https://github.com/Featurehouse/sweet_potato-source
How to trigger: use IntelliJ IDEA’s Gradle Sync.

[modmuss50]

This appears to be a bug in gradle’s native code here:

https://github.com/gradle/native-platform/blob/cfe37a669f31f4b5b8b252462a0b221e054b4a19/native-platform/src/main/cpp/win.cpp#L135-L142

This is becuase on a FAT file stystem GetFileInformationByHandleEx fails with error ERROR_INVALID_PARAMETER.

I have a found a few examples of other projects working around this:

https://github.com/golang/go/commit/e4535772ca3f11084ee5fa4d4bd3a542e143b80f https://github.com/coreutils/gnulib/blob/master/lib/stat-w32.c#L218-L219

I was also able to reproduce this by building a minimal c++ test case based off the gradle code.

#include <iostream>
#include <windows.h>

int main()
{
    DWORD dwFlagsAndAttributes = FILE_FLAG_BACKUP_SEMANTICS | FILE_FLAG_OPEN_REPARSE_POINT;
    HANDLE fileHandle = CreateFileW(
        LR"(G:\fabric-example-mod-1.17\.gradle\loom-cache\remapped_mods\net_fabricmc_yarn_1_17_1_17_build_13_v2\net\fabricmc\fabric-api\fabric-api\0.36.0+1.17\fabric-api-0.36.0+1.17.pom)",
        GENERIC_READ,
        FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE,
        NULL,
        OPEN_EXISTING,
        dwFlagsAndAttributes,
        NULL
    );

    if (fileHandle == INVALID_HANDLE_VALUE) {
        DWORD error = GetLastError();
        std::cout << "not ok!" << std::endl;
        return error;
    }

    BY_HANDLE_FILE_INFORMATION fileInfo;
    BOOL ok = GetFileInformationByHandle(fileHandle, &fileInfo);
    if (!ok) {
        DWORD error = GetLastError();
        CloseHandle(fileHandle);
        return error;
    }

    FILE_ATTRIBUTE_TAG_INFO fileTagInfo;
    BOOL ok = GetFileInformationByHandleEx(fileHandle, FileAttributeTagInfo, &fileTagInfo, sizeof(fileTagInfo));
    if (!ok) {
        DWORD error = GetLastError();
        CloseHandle(fileHandle);
        std::cout << "not ok!" << std::endl;
        return error;
    }

    CloseHandle(fileHandle);

    std::cout << "ok" << std::endl;
}

I will look into making a bug report and a pull request to gradle to fix this issue once I have had a chance to look over it a bit more at a sensible time of day. For now the workaround is to not use FAT file systems.

Big thanks to @teddyxlandlee for figuring out it was based on the file system as this unlocked the key to being able to get a debugger in there, and I would have never been able to find it without that information.

[teddyxlandlee]

Update: All of my tests were processed on my exFAT USB disk. No problems on NTFS. No problems with non-Fabric gradle projects. Is Tiny Remapper or Gradle itself incompatible with exFAT file system?
Let me try to use FabricMC/TinyRemapper to remap jars on my USB disk.
On my USB disk, I tried this: java -jar tiny-remapper-0.4.2-fat.jar minecraft-1.16.5-merged.jar minecraft-1.16.5-intermediary.jar 1.16.5.tiny official intermediary and succeeded with Finished after 9953.32 ms..
So this may be an issue between Gradle (or loom itself) and exFAT file system