From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22709 invoked by alias); 4 Dec 2013 03:47:39 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 22700 invoked by uid 89); 4 Dec 2013 03:47:39 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_50,RDNS_NONE,SPF_SOFTFAIL,URIBL_BLOCKED autolearn=no version=3.3.2 X-HELO: mtaout23.012.net.il Received: from Unknown (HELO mtaout23.012.net.il) (80.179.55.175) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 04 Dec 2013 03:47:37 +0000 Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0MX900300JD55K00@a-mtaout23.012.net.il> for gdb@sourceware.org; Wed, 04 Dec 2013 05:47:28 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MX9003UNJV43890@a-mtaout23.012.net.il>; Wed, 04 Dec 2013 05:47:28 +0200 (IST) Date: Wed, 04 Dec 2013 03:47:00 -0000 From: Eli Zaretskii Subject: Re: Unreliable BFD caching heuristic In-reply-to: <529E709F.6050008@codesourcery.com> To: lgustavo@codesourcery.com Cc: petr.hluzin@gmail.com, tromey@redhat.com, gdb@sourceware.org, macro@codesourcery.com Reply-to: Eli Zaretskii Message-id: <83a9gh46qz.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8BIT References: <528E454F.6060003@codesourcery.com> <87a9gjw97b.fsf@fleche.redhat.com> <529DF865.2070104@codesourcery.com> <529E709F.6050008@codesourcery.com> X-IsSubscribed: yes X-SW-Source: 2013-12/txt/msg00007.txt.bz2 > Date: Tue, 03 Dec 2013 22:00:31 -0200 > From: Luis Machado > CC: Tom Tromey , gdb , "Maciej W. Rozycki" > > On 12/03/2013 09:33 PM, Petr Hluzín wrote: > > > > On 3 December 2013 16:27, Luis Machado > > wrote: > > > I did an experiment with using the inode number in the cache check. > > It seems > > > to work for the hosts that support that information. On Windows i > > think we > > > fake inode numbers based on the file name and timestamp, so it could be a > > > simpler solution. > > > > > > Luis > > > > On Windows you can use GetFileInformationByHandle() function, see > > http://msdn.microsoft.com/en-us/library/aa364952.aspx > > Thanks, but i don't think we would like to have windows-specific calls > in such a generic portion of code. I don't understand: if you want to use inode numbers on Posix systems, which requires a Unix-specific call, then why not use GetFileInformationByHandle, which gives the Windows equivalent of the inode? IOW, if you can have _real_ inodes on Windows, why risk the fake ones?