On Nov 2 04:38, Jonathan Lennox wrote: > On Wednesday, October 21 2015, "Corinna Vinschen" wrote to "cygwin@cygwin.com" saying: > > On Oct 8 12:16, Jonathan Lennox wrote: > > > No such luck, despite two major version revisions of Parallels Desktop (I'm > > > now on version 11.0.2) and moving to Windows 10 as the guest OS -- the bug > > > perists, unchanged. So it looks like Cygwin will need to add a workaround > > > for this filesystem to fix the problem. > > > > Ok, we could do that. Can you compile and run the testcase from > > https://cygwin.com/ml/cygwin/2014-04/msg00523.html again? Does it > > still show 0 vs. 12 bytes? Dumb extra test: Does the output change > > if you reorder the calls, requesting FileStandardInformation first, > > FileNetworkOpenInformation second? > > I re-ran the test, no change. Changing the order gives the same result -- > FileStandardInformation works, FileNetworkOpenInformation doesn't. Ok, so it's not about some caching. > > Just create a hardlink on that drive using native means: > > > > $ touch foo > > $ cmd /c mklink /h bar foo > > > > Error at this point? No hardlinks. Otherwise: > > "You do not have sufficient privilege to perform this operation." Is that > sufficient proof? No. > Unfortunately, when I do "Run As Administrator" on MinTTY, the Mac drives > (/cygdrive/z and /cygdrive/y) don't show up. I don't know why that is. So I > can't test hard links as administrator. That's a security feature of UAC. You can change that in the registry. As administrator: regtool -d set /HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/Windows/CurrentVersion/Policies/System/EnableLinkedConnections 1 Then reboot. > > $ ls -li foo bar > > > > Are the inode numbers identical? Congrats, hardlinks work. But given > > the general FAT-iness of the getVolInfo output, I guess it doesn't > > maintain hardlinks. > > However, when I create a hardlink on the underlying (Mac) file system, the > inode numbers that Cygwin shows are not identical. So "no hardlinks" seems > very likely. Given the filesystem flags, Cygwin treats your FS as some kind of FAT anyway, so this isn't convincing. I doubt they work anyway, but if you really want to test it, use your orignal testcase and replace the NtQueryInformationFile like this: FILE_INTERNAL_INFORMATION fii; status = NtQueryInformationFile (h, &io, &fii, sizeof fii, FileInternalInformation); if (!NT_SUCCESS (status)) fprintf (stderr, "NtQueryInformationFile: 0x%08x\n", status); else printf ("inode number %llu\n", fii.FileId.QuadPart); Then call this application multiple times on some well known hardlinks to the same file. If they have the same number, all the time, hardlinks work. I added support for this filesystem (called prlfs in mount output) and without hardlink support for now. I uploaded a new developer snapshot to https://cygwin.com/snapshots/ Please give it a try. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat