On Feb 3 22:14, Dan Shelton via Cygwin wrote:
> On Tue, 3 Feb 2026 at 13:20, Corinna Vinschen via Cygwin
> <[email protected]> wrote:
> >
> > On Feb 3 00:55, Dan Shelton via Cygwin wrote:
> > > On Mon, 2 Feb 2026 at 17:04, Corinna Vinschen via Cygwin
> > > <[email protected]> wrote:
> > > >
> > > > On Feb 2 14:47, Dan Shelton via Cygwin wrote:
> > > > > On Mon, 2 Feb 2026 at 14:40, Corinna Vinschen via Cygwin
> > > > > <[email protected]> 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
