On Apr 23 12:47, len...@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
pgpu8bqzg5WVs.pgp
Description: PGP signature
