From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 47470 invoked by alias); 8 Oct 2015 16:16:50 -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 47459 invoked by uid 89); 8 Oct 2015 16:16:50 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.3 required=5.0 tests=AWL,BAYES_20,KAM_LAZY_DOMAIN_SECURITY autolearn=no version=3.3.2 X-HELO: mailbackend.panix.com Received: from mailbackend.panix.com (HELO mailbackend.panix.com) (166.84.1.89) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Thu, 08 Oct 2015 16:16:48 +0000 Received: from compute03.cs.columbia.edu (compute03.cs.columbia.edu [128.59.11.33]) by mailbackend.panix.com (Postfix) with ESMTPA id 759F716CF3 for ; Thu, 8 Oct 2015 12:16:46 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22038.38637.802707.846218@compute03.cs.columbia.edu> Date: Thu, 08 Oct 2015 16:16:00 -0000 From: Jonathan Lennox To: cygwin@cygwin.com Subject: Re: fstat st_size on open files on Parallels filesystem is wrong In-Reply-To: <20140423172413.GQ2339@calimero.vinschen.de> 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> <20140423172413.GQ2339@calimero.vinschen.de> X-SW-Source: 2015-10/txt/msg00094.txt.bz2 Hi, following up on this issue from last year. The message I'm replying to is at . The problem is weird behavior in Parallels Desktop-hosted Windows VMs, when accessing the host's native Mac OS X filesystem. See the thread for the details. On Wednesday, April 23 2014, "Corinna Vinschen" wrote to "cygwin@cygwin.com" saying: > > 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. 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. The output of /usr/lib/csih/getVolInfo seems to be unchanged from the output I reported last year. > 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. How would I figure these points out? -- Jonathan Lennox lennox@cs.columbia.edu -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple