DMARC-Filter: OpenDMARC Filter v1.4.2 delorie.com 613LGZBt4029706
DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 88B354BA2E08
MIME-Version: 1.0
References: <CAAvCNcDzoq3skCwRuYa2LLTTA3xsnK+eDLB8_SegJZinatMUSg@mail.gmail.com>
 <fc1bdd5b-7732-4430-a130-70ef662acd36@dronecode.org.uk>
 <CAAvCNcAAoJeX470QBp9x+A=zSupb_5TpVDeqnbsJS9dtd-oXQg@mail.gmail.com>
 <aYCpYYE1scT7bdaA@calimero.vinschen.de>
 <CAAvCNcASN+pduqG1LT6S1nZhd02-7vFdj5WNNpgkDbrMgV2ZxQ@mail.gmail.com>
 <aYDLGpPYXd0WDSZu@calimero.vinschen.de>
 <CAAvCNcCX6JpMkra_+8nmm3BD0OsZSWwE7EG6JJ5Ab0BwWWkU_Q@mail.gmail.com>
 <aYHn-0fJM2p1KKC3@calimero.vinschen.de>
In-Reply-To: <aYHn-0fJM2p1KKC3@calimero.vinschen.de>
Date: Tue, 3 Feb 2026 22:14:00 +0100
Message-ID: <CAAvCNcB5w4EH+P1s9_4OzPzFBP6SDRc4nmgVpOzBjcm8fY=06g@mail.gmail.com>
Subject: Re: git fsck complains about error:
 refs/tags/.cyg000000000559e25517156b51cf219f51/libgcj-2.95.0:
 badRefName: invalid refname format?!
To: cygwin@cygwin.com
From: Dan Shelton via Cygwin <cygwin@cygwin.com>
Reply-To: Dan Shelton <dan.f.shelton@gmail.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: "Cygwin" <cygwin-bounces~archive-cygwin=delorie.com@cygwin.com>

On Tue, 3 Feb 2026 at 13:20, Corinna Vinschen via Cygwin
<cygwin@cygwin.com> wrote:
>
> On Feb  3 00:55, Dan Shelton via Cygwin wrote:
> > On Mon, 2 Feb 2026 at 17:04, Corinna Vinschen via Cygwin
> > <cygwin@cygwin.com> wrote:
> > >
> > > On Feb  2 14:47, Dan Shelton via Cygwin wrote:
> > > > On Mon, 2 Feb 2026 at 14:40, Corinna Vinschen via Cygwin
> > > > <cygwin@cygwin.com> wrote:
> > > > >
> > > > > On Feb  2 13:24, Dan Shelton via Cygwin wrote:
> > > > > > 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.
> > > > >
> > > > > Your testcase is incorrect, unfortunately.
> > > > >
> > > > > >     fri->FileNameLength = (wcslen(dstfile)+1)*sizeof(wchar_t);
> > > > >
> > > > > For NT file paths, never count the trailing \0 to the length:
> > > > >
> > > > >       fri->FileNameLength = wcslen(dstfile) * sizeof (WCHAR);
> > > > >
> > > > > With that, your testcase works fine for me.
> > > > >
> > > > > On which filesystem did you see the problem?
> > > >
> > > > Windows NFSv3 client (the builtin one, not the newer NFSv4.1 one).
> > >
> > > The files in question are actually files which got renamed while
> > > in use.  I don't know another way to implement removing in-use files
> > > on remote file systems not supporting delete POSIX semantics.  If
> > > somebody has a brilliant idea, https://cygwin.com/acronyms/#PTC.
> >
> > Did you see that these are directories, not files? How does that happen?
>
> Yes, I saw that.  Same as for files.  Basically something like this:
>
>   mkdir ("dir");
>   fd = open ("dir", O_DIRECTORY);
>   unlink ("dir");
>   fd2 = openat (fd, "file", O_CREAT...);

I'm pretty sure this is a bug in Cygwin, unlink() should not work on dirs
1. unlink() is only defined for files, but not dirs. POSIX says ...
The path argument shall not name a directory ...
2. The /bin/unlink.exe utility says it can only work on files
3. Looking at the SystemV sources you see the NFS client code only
creates .nfsXXXXX files for files, but NEVER for directories
4. Testing this on Solaris 10 Update 8 says the dir is not empty
5. It really breaks git and git's test suite

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