Re: fstat st_size on open files on Parallels filesystem is wrong

[Corinna Vinschen <corinna-cygwin@cygwin.com>]

[-- Attachment #1: Type: text/plain, Size: 3175 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]