DMARC-Filter: OpenDMARC Filter v1.4.2 delorie.com 612CQ16E3128160
DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 334BD4BA9035
MIME-Version: 1.0
References: <CAAvCNcDzoq3skCwRuYa2LLTTA3xsnK+eDLB8_SegJZinatMUSg AT mail DOT gmail DOT com>
 <fc1bdd5b-7732-4430-a130-70ef662acd36 AT dronecode DOT org DOT uk>
In-Reply-To: <fc1bdd5b-7732-4430-a130-70ef662acd36@dronecode.org.uk>
Date: Mon, 2 Feb 2026 13:24:31 +0100
Message-ID: <CAAvCNcAAoJeX470QBp9x+A=zSupb_5TpVDeqnbsJS9dtd-oXQg@mail.gmail.com>
Subject: Re: git fsck complains about error:
 refs/tags/.cyg000000000559e25517156b51cf219f51/libgcj-2.95.0:
 badRefName: invalid refname format?!
To: cygwin AT cygwin DOT com
From: Dan Shelton via Cygwin <cygwin AT cygwin DOT com>
Reply-To: Dan Shelton <dan DOT f DOT shelton AT gmail DOT com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: "Cygwin" <cygwin-bounces~archive-cygwin=delorie DOT com AT cygwin DOT com>

On Sun, 1 Feb 2026 at 18:08, Jon Turney <jon DOT turney AT dronecode DOT org DOT uk> wrote:
>
> On 31/01/2026 18:42, Dan Shelton via Cygwin wrote:
> > Hello, on Cygwin 3.6.6-1.x86_64 on CYGWIN_NT-10.0-19045/Win10 I get
> > these errors from git fsck when working on a clean clone of the
> > gcc.git repro:
> >
> > git fsck
> > error: refs/tags/.cyg000000000559e25517156b51cf219f51/libgcj-2.95.1:
> > badRefName: invalid refname format
> > error: refs/tags/.cyg000000000559e25517156b51cf219f51/libgcj-2.95.0:
> > badRefName: invalid refname format
> > error: refs/tags/.cyg000000000559e25817156b51cf219f51/libf2c-0.5.22:
> > badRefName: invalid refname format
> > error: refs/tags/.cyg000000000559e25817156b51cf219f51/libf2c-0.5.21:
> > badRefName: invalid refname format
> >
> > git fsck then exits with error code 8, breaking our scripts.
> >
> > Is this a Cygwin bug or feature running wild?
> Yes.
>
> These .cygXXX files are made by the cygwin DLL (I think it's something
> like a hardlink to the running executable so we can fork even if it's
> deleted, but I might well be misremembering the details) and are
> supposed to get automatically removed.
>
> Obviously, 'git fsck' objects to their presence, but it is safe to
> remove them.

I'm not sure whether the Cygwin code is correct. I did a peek with a
kernel debugger, and I see that FILE_RENAME_INFORMATION.RootDirectory
is always NULL if a file gets renamed to .cyg000000000xxxx. But if I
try that with NTFS or SMB, the NtSetInformationFile() to set
FileRenameInformation always fails.

I think this bug is there since a LONG time, and only bothers
filesystems which are not NTFS.

I made this testcase:
-x-x-x-x-x-x-x-x-x-x-x-x-
#include <windows.h>
#include <wchar.h>
#include <stdbool.h>
#include <stdio.h>
#include <stdint.h>
#include <stddef.h>

#ifdef _MSC_VER
#pragma comment(lib, "ntdll.lib")
#endif

typedef LONG NTSTATUS;
#ifndef NT_SUCCESS
#define NT_SUCCESS(Status) (((NTSTATUS)(Status)) >= 0)
#endif

typedef struct _IO_STATUS_BLOCK {
    union { NTSTATUS Status; PVOID Pointer; } DUMMYUNIONNAME;
    ULONG_PTR Information;
} IO_STATUS_BLOCK, *PIO_STATUS_BLOCK;

typedef enum _FILE_INFORMATION_CLASS {
    FileRenameInformation = 10
} FILE_INFORMATION_CLASS;

typedef struct _FILE_RENAME_INFORMATION {
    BOOLEAN ReplaceIfExists;
    HANDLE  RootDirectory;
    ULONG   FileNameLength;
    WCHAR   FileName[1];
} FILE_RENAME_INFORMATION, *PFILE_RENAME_INFORMATION;

#ifdef __cplusplus
extern "C" {
#endif
NTSTATUS NTAPI NtSetInformationFile(HANDLE, PIO_STATUS_BLOCK, PVOID,
ULONG, FILE_INFORMATION_CLASS);
ULONG NTAPI RtlNtStatusToDosError(NTSTATUS);
#ifdef __cplusplus
}
#endif

static HANDLE OpenForRenameW(const wchar_t* fullDosPath)
{
    DWORD share  = FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE;
    DWORD flags  = FILE_FLAG_BACKUP_SEMANTICS | FILE_FLAG_OPEN_REPARSE_POINT;
    return CreateFileW(fullDosPath, GENERIC_READ | DELETE |
SYNCHRONIZE, share, NULL, OPEN_EXISTING, flags, NULL);
}

int wmain(int ac, wchar_t *av[])
{
    wchar_t *srcfile = av[1];
    wchar_t *dstfile = av[2];

    if (ac != 3) {
        fwprintf(stderr, L"%ls: Usage: renametest <srcfile>
<dstfile>\n", av[0]);
        return 2;
    }

    HANDLE srch = OpenForRenameW(srcfile);
    if (srch == INVALID_HANDLE_VALUE) {
        fwprintf(stderr, L"%ls: Cannot open srcfile, lasterr=%d\n",
av[0], (int)GetLastError());
    }

    PFILE_RENAME_INFORMATION fri;
    size_t fri_len = sizeof(FILE_RENAME_INFORMATION) +
(wcslen(dstfile)+1)*sizeof(wchar_t);

    fri = calloc(1, fri_len);
    if (fri == NULL) {
        fwprintf(stderr, L"%ls: Out of memory\n", av[0]);
        return 2;
    }
    fri->ReplaceIfExists = TRUE;
    fri->RootDirectory = NULL;
    fri->FileNameLength = (wcslen(dstfile)+1)*sizeof(wchar_t);
    memcpy(&fri->FileName[0], dstfile, fri->FileNameLength);

    IO_STATUS_BLOCK isb = { 0 };

    NTSTATUS status = NtSetInformationFile(srch, &isb, fri, fri_len,
FileRenameInformation);
    printf("ntstatus=0x%lx\n", (long)status);

    CloseHandle(srch);

    return EXIT_SUCCESS;
}
-x-x-x-x-x-x-x-x-x-x-x-x-

Dan
-- 
Dan Shelton - Cluster Specialist Win/Lin/Bsd

-- 
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple