From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by olra.theworths.org (Postfix) with ESMTP id 439CA431FBC for ; Thu, 14 Jan 2010 14:42:43 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at olra.theworths.org X-Spam-Flag: NO X-Spam-Score: -1.825 X-Spam-Level: X-Spam-Status: No, score=-1.825 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1.8, AWL=-0.026, BAYES_50=0.001] autolearn=ham Received: from olra.theworths.org ([127.0.0.1]) by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nz-OTXjGLAoP; Thu, 14 Jan 2010 14:42:42 -0800 (PST) Received: from yoom.home.cworth.org (localhost [127.0.0.1]) by olra.theworths.org (Postfix) with ESMTP id 72787431FAE; Thu, 14 Jan 2010 14:42:42 -0800 (PST) Received: by yoom.home.cworth.org (Postfix, from userid 1000) id E0A01550090; Thu, 14 Jan 2010 14:42:41 -0800 (PST) From: Carl Worth To: Adrian Perez de Castro , notmuch@notmuchmail.org In-Reply-To: <20100114183854.1d04f111@hikari> References: <4B4ED7E8.20501@exys.org> <878wc0623y.fsf@exys.org> <20100114183854.1d04f111@hikari> Date: Thu, 14 Jan 2010 14:42:41 -0800 Message-ID: <87fx68e2am.fsf@yoom.home.cworth.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Subject: Re: indexing mail? X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "Use and development of the notmuch mail system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2010 22:42:43 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Thu, 14 Jan 2010 18:38:54 +0100, Adrian Perez de Castro wrote: > > the offending commit is 2c4555f1a56602ff1dd55a63699810522ba4d91e > >=20 > > from readdir (3): > >=20 > > "Currently, only some file systems (among them: Btrfs, ext2, ext3, > > and ext4) have full support returning the file > > type in d_type. All applications must properly handle a return > > of DT_UNKNOWN." Yes. The broken code was my mistake. I clearly didn't read the above warning closely enough. Sorry about that! > I am using XFS, which always returns DT_UNKNOWN. Taking into account that > there is a good deal of people using filesystems other than the ones you > mention, and that other non-linux filesystems may also return DT_UNKNOWN, > in my opinion there should be a fall-back. I will try to post a patch > Anytime Soon=E2=84=A2. We definitely want the fallback. I can attempt to code it, but I don't have ready access to an afflicted filesystem, so I'd need help testing anyway. I'd love to see a patch for this bug soon. Be sure to CC me when the patch is sent and that will help me commit it sooner. > Also, I have the feeling that the "d_type" field from "struct dirent" may > not be available in some OSes because it is a BSD extension. I'm generally quite bad at determining whether functionality I'm using in my software is non-portable. As proven in this case, even when the man page tells me something is not portable I don't always notice, (and often, the man pages aren't even that useful). Beyond that, even if something is *known* to be theoretically non-portable, it can be a waste of time to code compatibility paths that nobody will be running in practice. So I've basically gotten to the point where I just code for what works on my system, (not out of disregard for what other people run---just that it's impossible for me to know what subset of functionality is actually relevant). Then, at the same time, I'm quite happy to accept code to improve the portability when people note that things are broken on other systems. See the git history and email archives for examples of how we fixed strndup and getline portability problems. I know that "wait for people to notice it's broken" isn't the nicest thing we could do with our code. But I don't really know a much better way. I'm happy to entertain suggestions here. =2DCarl --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iD8DBQFLT53h6JDdNq8qSWgRArt3AJwJwYb7MWcyM4KqxJrsmrPcDPL9LgCgkdvY hCOpr8bn3wgfuIQCcb+BpPU= =s9vi -----END PGP SIGNATURE----- --=-=-=--