From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12108 invoked by alias); 23 Apr 2014 17:24:18 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 12095 invoked by uid 89); 23 Apr 2014 17:24:18 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-5.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.2 X-HELO: calimero.vinschen.de Received: from aquarius.hirmke.de (HELO calimero.vinschen.de) (217.91.18.234) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 23 Apr 2014 17:24:17 +0000 Received: by calimero.vinschen.de (Postfix, from userid 500) id 3BAA58E142F; Wed, 23 Apr 2014 19:24:13 +0200 (CEST) Date: Wed, 23 Apr 2014 17:24:00 -0000 From: Corinna Vinschen To: cygwin@cygwin.com Subject: Re: fstat st_size on open files on Parallels filesystem is wrong Message-ID: <20140423172413.GQ2339@calimero.vinschen.de> Reply-To: cygwin@cygwin.com Mail-Followup-To: cygwin@cygwin.com References: <21333.25325.11106.958642@compute01.cs.columbia.edu> <227151856.20140421223417@yandex.ru> <21333.26515.393838.380071@compute01.cs.columbia.edu> <20140422081628.GC2339@calimero.vinschen.de> <21334.55207.784319.488271@compute01.cs.columbia.edu> <20140423084056.GJ2339@calimero.vinschen.de> <21335.61113.963950.516021@compute01.cs.columbia.edu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wAI/bQb0EMvlZCHl" Content-Disposition: inline In-Reply-To: <21335.61113.963950.516021@compute01.cs.columbia.edu> User-Agent: Mutt/1.5.21 (2010-09-15) X-SW-Source: 2014-04/txt/msg00524.txt.bz2 --wAI/bQb0EMvlZCHl Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 3090 On Apr 23 12:47, lennox@cs.columbia.edu wrote: > On Wednesday, April 23 2014, "Corinna Vinschen" wrote to "cygwin at cygwi= n.com" saying: >=20 > > Rather than calling GetFileInformationByHandle, try this > > [...] > Okay, looks like FileNetworkOpenInformation is succeeding, but returning a > bad EndOfFile value. >=20 > $ ./win32-size-test 'z:\foo' > z:\foo: NtQueryInformationFile(FileNetworkOpenInformation): EndOfFile=3D0 > z:\foo: NtQueryInformationFile(FileStandardInformation): EndOfFile=3D12 >=20 > $ 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=3D0 > z:\\foo: NtQueryInformationFile(FileStandardInformation): EndOfFile=3D12 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: > >=20 > > $ /usr/lib/csih/getVolInfo /cygdrive/z >=20 > $ /usr/lib/csih/getVolInfo.exe /cygdrive/z/ > Device Type : 7 > Characteristics : 10 > Volume Name : > Serial Number : 0 > Max Filenamelength : 255 > Filesystemname : > 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=3D=3DFALSE so, never mind. OTOH, does it support hardlinks? If so, two hardlinks to the same file would have different inode numbers on Cygwin. Corinna --=20 Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat --wAI/bQb0EMvlZCHl Content-Type: application/pgp-signature Content-length: 819 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJTV/c9AAoJEPU2Bp2uRE+gP9cP/AkkthuH4x71OHtCpa97WLs4 TTNFnPOpSxBRnwwqkd/nJKDkRyV+HIMxAL9fCu4QwEl7nNXuSX1WHJlnNqBcOr/h RFsLdTtDBxzgECcZ2T4FtGoyfxqO5dbKIBzt+QFMLoy8A2twClCvcpaHpxt9JUzs D2t3MZcS7KhActXf7uhSPzKbLYPI6C8z8KN36pOn+tTBwO3fhTDc2C3c/dExf+N6 EriNtc8Jb3hOCRYKoWnGTSpEzdN+KGOw9gFlFoMOplip6ZnwwLCO4C77D1nl9B6T y+Xilw4VjbSIoIKEeUTmrVskmsjSsz1qjLk9Wd1PoAakLUkixVR9fXlBRWRyx/it x2F6J2XEIgzhQjWhTKk6feujiisyafoXbNXkU34llvQKJR7ISLbG3Erqjs359/jp xOo8BAR9pwfjbdsR0SluQ7coiCXfC3JmiXeHC+Vhgd2ycnicmW06Mowkk7Nma0SH U13VzcmmknhzMrwbCfCfz12vIdX0l17GRZMvAqA5T5NMyzT/iuuH1XY9RhAQagPT DRqW1RW6C4gFRIZtkkpVfroz71Xg/AVY13CV0OwieN6J+GOHVAJ/SZusNwIBKNgE 688EJJn3HOfK4UG0vwrVbOtG8rZgrv7hPX4v8qQkw2n07xx5RVjn/hlXvNvA6Egp oRXMO48BXohKODChEF7L =dJkS -----END PGP SIGNATURE----- --wAI/bQb0EMvlZCHl--