Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-developers-owner AT sourceware DOT cygnus DOT com Delivered-To: mailing list cygwin-developers AT sourceware DOT cygnus DOT com From: Chris Faylor Date: Thu, 9 Dec 1999 00:54:18 -0500 To: Andrew Dalgleish Cc: cygwin-developers AT sourceware DOT cygnus DOT com Subject: Re: winsup inode bug + patch Message-ID: <19991209005418.A18096@cygnus.com> Mail-Followup-To: Andrew Dalgleish , cygwin-developers AT sourceware DOT cygnus DOT com References: <00F8D6E8AB0DD3118F1A006008186C9607C7CA AT server1 DOT axonet DOT com DOT au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <00F8D6E8AB0DD3118F1A006008186C9607C7CA@server1.axonet.com.au>; from andrewd@axonet.com.au on Wed, Dec 08, 1999 at 04:46:57PM +1100 On Wed, Dec 08, 1999 at 04:46:57PM +1100, Andrew Dalgleish wrote: >There is a bug in the current handling of a file's inode. >I first noticed this when a "mv" failed on a remote drive. > >This is most easily verified by doing an "ls -i". >The listed inodes are not unique, and are not always the same for a >given file even when you execute "ls -i foo && ls -i foo". > >Using nFileIndexHigh and nFileIndexLow for an inode number is taking a >leap of faith. > >Here is the relevant section from the VC6 help (my line wrapping): > > nFileIndexLow > Specifies the low-order word of a unique identifier associated with >the file. > This identifier and the volume serial number uniquely identify a file. > This number may change when the system is restarted or when the file >is opened. > After a process opens a file, the identifier is constant until the >file is closed. > An application can use this identifier and the volume serial number to >determine whether two handles refer to the same file. > >Note the phrase "the identifier is constant until the file is closed". >The current code in stat() opens and closes the file. Yes. I was aware of this problem with remote shares but I'd never bothered to look in to fixing this. I appreciate the effort that went into tracking this down but I think it makes more sense to just add your code to the one place in cygwin where it is calculating inodes than to every single file path operation. So, in the next snapshot, you should see that I've done essentially what you've done in path.cc in fhandler_base.cc around the place where it does the inode calculation. Btw, have you sent in an assignment to us? If not, please go to the sourceware.cygnus.com web page and follow the links for contributing. There is an assignment form that we'll need for you to be able to contribute software to the project. Apologies if you've already done this and I just forgot. Thanks again for tracking this down so well. -chris