On Apr 23 12:47, lennox@cs.columbia.edu wrote:
> On Wednesday, April 23 2014, "Corinna Vinschen" wrote to "cygwin at cygwin.com" saying:
> 
> > Rather than calling GetFileInformationByHandle, try this
> > [...]
> Okay, looks like FileNetworkOpenInformation is succeeding, but returning a
> bad EndOfFile value.
> 
> $ ./win32-size-test 'z:\foo'
> z:\foo: NtQueryInformationFile(FileNetworkOpenInformation): EndOfFile=0
> z:\foo: NtQueryInformationFile(FileStandardInformation): EndOfFile=12
> 
> $ gdb --quiet --args ./win32-size-test.exe 'z:\foo'
> Reading symbols from /cygdrive/z/Emacs-Modtime/win32-size-test.exe...done.
> (gdb) break 82
> Breakpoint 1 at 0x100401400: file win32-size-test.c, line 82.
> (gdb) run
> Starting program: /cygdrive/z/Emacs-Modtime/win32-size-test.exe z:\\foo
> [New Thread 10540.0x48dc]
> [New Thread 10540.0x39d4]
> z:\\foo: NtQueryInformationFile(FileNetworkOpenInformation): EndOfFile=0
> z:\\foo: NtQueryInformationFile(FileStandardInformation): EndOfFile=12

Wow, strange.

> At this point this is looking pretty clearly like a Parallels Tools bug.
> I'll report it to them.

Yes, that sounds good.  Given that, I'm wondering if we should try to
workaround this problem at all or rather wait to see if the vendor will
fix the issue.

> > Also, to add handling for the Parallels filesystem to Cygwin, I'd
> > need the info printed by the getVolInfo tool from the csih package:
> > 
> >   $ /usr/lib/csih/getVolInfo /cygdrive/z
> 
> $ /usr/lib/csih/getVolInfo.exe /cygdrive/z/
> Device Type        : 7
> Characteristics    : 10
> Volume Name        : <Shared Folders>
> Serial Number      : 0
> Max Filenamelength : 255
> Filesystemname     : <PrlSF>
> Flags              : 3
>   FILE_CASE_SENSITIVE_SEARCH  : TRUE
>   FILE_CASE_PRESERVED_NAMES   : TRUE
>   FILE_UNICODE_ON_DISK        : FALSE
>   FILE_PERSISTENT_ACLS        : FALSE
>   FILE_FILE_COMPRESSION       : FALSE
>   FILE_VOLUME_QUOTAS          : FALSE
>   FILE_SUPPORTS_SPARSE_FILES  : FALSE
>   FILE_SUPPORTS_REPARSE_POINTS: FALSE
>   FILE_SUPPORTS_REMOTE_STORAGE: FALSE
>   FILE_VOLUME_IS_COMPRESSED   : FALSE
>   FILE_SUPPORTS_OBJECT_IDS    : FALSE
>   FILE_SUPPORTS_ENCRYPTION    : FALSE
>   FILE_NAMED_STREAMS          : FALSE
>   FILE_READ_ONLY_VOLUME       : FALSE
>   FILE_SEQUENTIAL_WRITE_ONCE  : FALSE
>   FILE_SUPPORTS_TRANSACTIONS  : FALSE

Thanks.  This looks pretty much like a filesystem pretending to be
FAT-like.  There may be another problem lurking, which is, are the inode
numbers (called "FileId" or "IndexNumber" in Windows) persistant?  With
FAT this is not the case, and given the above, it might be a problem...

...or not.  I just realize that Cygwin doesn't even try to use the
FileId as inode number on filesystems with FILE_PERSISTENT_ACLS==FALSE
so, never mind.

OTOH, does it support hardlinks?  If so, two hardlinks to the
same file would have different inode numbers on Cygwin.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat