DMARC-Filter: OpenDMARC Filter v1.4.2 delorie.com 614AEEBS332830 Authentication-Results: delorie.com; dmarc=pass (p=none dis=none) header.from=cygwin.com Authentication-Results: delorie.com; spf=pass smtp.mailfrom=cygwin.com DKIM-Filter: OpenDKIM Filter v2.11.0 delorie.com 614AEEBS332830 Authentication-Results: delorie.com; dkim=pass (1024-bit key, unprotected) header.d=cygwin.com header.i=@cygwin.com header.a=rsa-sha256 header.s=default header.b=tCnXFvQs X-Recipient: archive-cygwin AT delorie DOT com DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org E8DFC4BA2E08 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com; s=default; t=1770200052; bh=30/YpibT2UWy9sdsKsUvPZqRj/AGz+PSQVJ/lh+LsbQ=; h=Date:To:Subject:References:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=tCnXFvQs29M6iS92dDBejaDLAuxeaEN1sSeN8t+CmtNVlZKPiGe4UfDC85ji0A1wT Hv3vOsAl4wcjSIloydymCkSNKGq8ZtonVh0bDog2UamAD1eEqvJTV1O/bMVxFGAQQn qWsWtZSsWctDm6FrxwcAJtcTENZRK+EGdKipHY1Y= X-Original-To: cygwin AT cygwin DOT com Delivered-To: cygwin AT cygwin DOT com DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org AB6974BA543C Date: Wed, 4 Feb 2026 11:13:25 +0100 To: cygwin AT cygwin DOT com Subject: Re: git fsck complains about error: refs/tags/.cyg000000000559e25517156b51cf219f51/libgcj-2.95.0: badRefName: invalid refname format?! Message-ID: Mail-Followup-To: cygwin AT cygwin DOT com References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-BeenThere: cygwin AT cygwin DOT com X-Mailman-Version: 2.1.30 Precedence: list List-Id: General Cygwin discussions and problem reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Corinna Vinschen via Cygwin Reply-To: cygwin AT cygwin DOT com Cc: Corinna Vinschen Content-Type: text/plain; charset="utf-8" Errors-To: cygwin-bounces~archive-cygwin=delorie DOT com AT cygwin DOT com Sender: "Cygwin" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by delorie.com id 614AEEBS332830 On Feb 3 22:14, Dan Shelton via Cygwin wrote: > On Tue, 3 Feb 2026 at 13:20, Corinna Vinschen via Cygwin > wrote: > > > > On Feb 3 00:55, Dan Shelton via Cygwin wrote: > > > On Mon, 2 Feb 2026 at 17:04, Corinna Vinschen via Cygwin > > > wrote: > > > > > > > > On Feb 2 14:47, Dan Shelton via Cygwin wrote: > > > > > On Mon, 2 Feb 2026 at 14:40, Corinna Vinschen via Cygwin > > > > > 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 ... Yeah, I was lazy. unlink("dir") returns EISDIR. Replace with rmdir("dir"). Under the hood it's all a single function unlink_nt(), though. > 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 See the code from https://sourceware.org/cgit/newlib-cygwin/tree/winsup/cygwin/syscalls.cc#n880 to https://sourceware.org/cgit/newlib-cygwin/tree/winsup/cygwin/syscalls.cc#n919 > 4. Testing this on Solaris 10 Update 8 says the dir is not empty Testing what on Solaris? In the above example the directory is created, then unlinked (yes, rmdir'ed) while it's still empty, and only then a file is created inside the dir via openat(). I didn't try this myself, it was just off the top of my head to create an unlinked dir with a file in it ¯\_(ツ)_/¯ > 5. It really breaks git and git's test suite I tried the same locally on MSFT NFS3 (git clone gcc.git; git fsck) twice and couldn't reproduce your problem. Corinna -- 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