From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 15 20:46:04 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C8B671065675 for ; Thu, 15 Mar 2012 20:46:04 +0000 (UTC) (envelope-from matthewstory@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 8179B8FC0C for ; Thu, 15 Mar 2012 20:46:04 +0000 (UTC) Received: by vcmm1 with SMTP id m1so4928790vcm.13 for ; Thu, 15 Mar 2012 13:46:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=rocZSySyhh4V5YWTzSUCUhmclVj05TsC9vN4lLanssI=; b=pI6KvRv8EqOCGU2q3wzcr9LSGvjOAN7wu61afWXPc/VFd93DmMHoxqbgqTLPSfMnTa pWN/9txNkq8+qq6KBnFwBEmy70z/OPoE/DNu4L3mr5p7Iu1r2Lw1cs2aL8/KnlZkcGZ7 8vXD8glH0xEf1WwxeE8BErt+Hbb7c3lBSpB0SzbXO+DYtBaIuFlxtBTp63a8cLG6hC/L hFCsC6f3Jsa4NZXihxdMsLSxrSgGmdkfZdtsC1eWYb8IKKkRgpyRcZkl5hsDPyK8zCsP l+HnEdV7moe8uVjvgu6F7YpsWMGDlDdhjuxfQcpS+qX0XcjJQXeOqhea+vdVSw+hLPix AwxA== MIME-Version: 1.0 Received: by 10.52.28.228 with SMTP id e4mr48900vdh.57.1331844363511; Thu, 15 Mar 2012 13:46:03 -0700 (PDT) Received: by 10.52.93.42 with HTTP; Thu, 15 Mar 2012 13:46:03 -0700 (PDT) Date: Thu, 15 Mar 2012 16:46:03 -0400 Message-ID: From: Matthew Story To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: FTSENT: name and path on `/' versus name and path on `*/' X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 20:46:04 -0000 Found a curious incongruent behavior in fts(3), wondering if there is some reason for this, or if it's just a bug. If you include the path `/' the FTSENT at depth 0 that is returned for the path has both fts_path = "/" and fts_name = "/", compared to other entries, like /var which has fts_path = "/" and fts_path = "/" and fts_name = "var", or /var/, which has fts_path = "/var/" and fts_name = "". Given the behavior of other paths used in fts(3), my expectation here is that FTSENT for path "/" on depth 0 would have fts_path = "/" and fts_name = "". Haven't delved down into the code enough to figure out where this is happening, but from a cursory read through libc/gen/fts.c there doesn't seem to be any explicit special casing of the path "/". Can anyone shed light on why this behavior is desirable, or if it's just a bug I'm happy to file a PR and delve further into fts.c ... -- regards, matt