Date: Mon, 19 Mar 2012 09:30:09 -0400 From: John Baldwin <jhb@freebsd.org> To: freebsd-hackers@freebsd.org Cc: Matthew Story <matthewstory@gmail.com> Subject: Re: FTSENT: name and path on `/' versus name and path on `*/' Message-ID: <201203190930.09782.jhb@freebsd.org> In-Reply-To: <CAB%2B9ogexA4aabM5zuJM2AUYrBgDS4_Nj2mfsZ5bQiv1NKBDHpw@mail.gmail.com> References: <CAB%2B9ogexA4aabM5zuJM2AUYrBgDS4_Nj2mfsZ5bQiv1NKBDHpw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thursday, March 15, 2012 4:46:03 pm Matthew Story wrote: > 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 ... My guess is that it is a bug. / is a bit special as it serves two purposes (i.e., both the idea of "/var" and "/var/" map to "/" for the root). -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201203190930.09782.jhb>