Mailing-List: contact users-help@subversion.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (athena.apache.org: local policy)
From: Bob Archer <Bob.Archer@amsi.com>
To: Gareth McCaughan <Gareth.McCaughan@lightblueoptics.com>,
	"users@subversion.apache.org" <users@subversion.apache.org>
Subject: RE: Subversion checked-out files not indexed in Windows search
Thread-Topic: Subversion checked-out files not indexed in Windows search
Thread-Index: Ac88bJuTOdmKGnmeR7mhWjAemACCpwABRJPg
Date: Mon, 10 Mar 2014 15:03:02 +0000
Message-ID: <EA9A16E4E64F694BAD262610B0A2515C2370E3A3@USALWEXMBX2.infor.com>
References: 
 <e09720270e094b3cbd04c8f6b29a6ee1@AMSPR05MB002.eurprd05.prod.outlook.com>
In-Reply-To: 
 <e09720270e094b3cbd04c8f6b29a6ee1@AMSPR05MB002.eurprd05.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

> It appears that files checked out using Subversion (1.7 onwards) are mark=
ed
> as not indexable by Windows search. The way in which this happens appears
> to be as follows:
>=20
> When the WC is created:
>=20
> 1. .svn directory is created, and marked as hidden and not indexable.
> 2. .svn/tmp directory is created, and inherits that not-indexable
>    property. (Or maybe it's given it explicitly; I haven't checked.)
>=20
> On checkout:
>=20
> 1. Temporary file is created under .svn, and accordingly gets its
>    not-indexable flag set.
> 2. Temporary file is moved to its proper location; this doesn't
>    cause the not-indexable flag to be cleared.
>=20
> So the point is that the NOT_CONTENT_INDEXABLE attribute on a directory
> doesn't exactly mean "don't search inside this directory"
> but "make files created in this directory searchable". Then when they get
> moved elsewhere they retain that unsearchability.
>=20
> (If skeptical, you can see this "by hand" on a Windows machine, as follow=
s:
> Create a directory A and subdirectory A\B. Right-click on B, select
> "Properties", select "Advanced", uncheck the allow-indexing box. Create t=
wo
> files A\B\C.txt and A\B\D.txt and put the word "wombat" in each. Now righ=
t-
> click D.txt, select "Properties", select "Advanced", and *check* the allo=
w-
> indexing box; and drag C.txt out of A\B and into A.
> Now, in A, search for "wombat" using Windows Search. It will find D.txt e=
ven
> though it's in the unsearchable folder A\B, and it will not find C.txt ev=
en
> though it's in the searchable folder A, because what actually matters is =
the
> attributes on the files.)
>=20
>=20
>                             *
>=20
> Windows Search is of course generally a poor tool for searching source co=
de,
> but this still seems fairly clearly (1) unintended and (2) undesirable.


Interesting. I was wondering just the other day why the contents of my sour=
ce files didn't seem to be indexed, even though the indexing rules from win=
dows search does include my development root. I had to use WinGrep to find =
what I was looking for.

>=20
> Should I file an issue? If not, will someone else?
>=20
>                             *
>=20
> I am not familiar with the code responsible for this, but a little browsi=
ng
> suggests that the rename is being done in svn_stream__install_stream
> (called from run_file_install in libsvn_wc/workqueue.c) by a call to
> SetFileInformationByHandle, and that this function is capable of changing=
 the
> file attributes at the same time as doing the rename. I make no claim tha=
t this
> would actually be a good solution.
>=20
>                             *
>=20
> (Note 1. This seems to have been reported informally a couple of times
> before, but I don't see that it's ever received an official answer, had a=
n issue
> filed in the Subversion issue tracker, or been fixed. Apologies if it has=
 and I've
> missed it.)
>=20
> (Note 2. I have observed the behaviour described above on Windows 7 using
> svn 1.7.5, and on Windows 8 using svn 1.8.3.
> There is nothing in the CHANGES file to suggest it's likely to have been =
fixed
> since then, but I can check with the latest release if that's necessary.)
>=20
> (Note 3. I am not subscribed to users@ but will check for replies in the =
online
> archives; best to Cc: me, though, if you have questions or comments you
> want to be sure I'll see.)
>=20
> --
> Gareth McCaughan