X-Spam-Check-By: sourceware.org Date: Sat, 21 Jan 2006 13:11:37 -0500 From: Christopher Faylor To: cygwin AT cygwin DOT com Subject: Re: question on d_ino semantics Message-ID: <20060121181137.GA6512@trixie.casa.cgf.cx> Reply-To: cygwin AT cygwin DOT com References: <43D0F45A DOT 9060408 AT byu DOT net> <2e59e6970601210645s2fb9137cq50578ef6cd118326 AT mail DOT gmail DOT com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2e59e6970601210645s2fb9137cq50578ef6cd118326@mail.gmail.com> User-Agent: Mutt/1.5.11 Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com On Sat, Jan 21, 2006 at 08:45:52AM -0600, * * wrote: >On 1/20/06, Eric Blake wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> There are currently two competing uses of d_ino semantics in coreutils: >> >> lib/backupfile.c assumes that if d_ino is ever 0, (captured by the macro >> REAL_DIR_ENTRY, which is always non-zero on platforms without d_ino), that >> readdir() returned an invalid entry and no attempt to dereference that >> name should be attempted. >> >> src/pwd.c assumes that if d_ino is ever 0, (captured by the macro D_INO, >> which is hardcoded to 0 on platforms without d_ino), that an lstat() >> should be attempted and the entry skipped if the stat failed, otherwise >> use st_ino. >> >> Cygwin currently has no d_ino member, because it is prohibitively >> expensive to provide it on WinNT and Win2K machines (the only way to make >> d_ino match st_ino on those two platforms is to perform the equivalent of >> a stat during readdir, but this penalizes the many apps which do not >> follow readdir with stat). But it is relatively trivial to provide d_ino > >In any other language.... this would be fairly easy. Make d_ino a >postponed call / functor that calls stat if and only if it is read. >Even with C++ this is possible. Is there any way for Cygwin to change >d_ino into some type of function call which can perform the processing >*on access*. I actually spent some time yesterday implementing something like this but it is very tricky to get right. The thing that seems to be lost in the noise here is that some applications are using d_ino in a way that makes no sense for Windows. I had a discussion about this in the git mailing list. They were using d_ino to sort update requests since, clusters of inodes are apt to be located close to each other on disk. Windows makes no such guarantee, though. I wonder if other applications are making similar assumptions and possibly would benefit from some code inspection and a "#ifdef __CYGWIN__". I hate to admit defeat about things like this but it really seems to me that this is one of those cases where the code has to be modified to work correctly on Windows/Cygwin. Inodes are a low-level detail on linux which we will never be able to get 100% right on cygwin. >Of course, this would be totally incompatible with anything that tries >to take the address of d_ino or write to it, but from the discussion, >that seems to be 0% of callers. But there are certainly applications which have variables called "d_ino". They would have to be changed. Btw, the latest snapshot implements "__USE_EXPENSIVE_CYGWIN_D_INO". If this is defined, then d_ino will be defined and filled out with the same inode information as derived by lstat(). cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/