> It appears that files checked out using Subversion (1.7 onwards) are marked
> as not indexable by Windows search. The way in which this happens appears
> to be as follows:
>
> When the WC is created:
>
> 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.)
>
> On checkout:
>
> 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.
>
> 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.
>
> (If skeptical, you can see this "by hand" on a Windows machine, as follows:
> Create a directory A and subdirectory A\B. Right-click on B, select
> "Properties", select "Advanced", uncheck the allow-indexing box. Create two
> files A\B\C.txt and A\B\D.txt and put the word "wombat" in each. Now right-
> click D.txt, select "Properties", select "Advanced", and *check* the allow-
> 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 even
> though it's in the unsearchable folder A\B, and it will not find C.txt even
> though it's in the searchable folder A, because what actually matters is the
> attributes on the files.)
>
>
> *
>
> Windows Search is of course generally a poor tool for searching source code,
> but this still seems fairly clearly (1) unintended and (2) undesirable.
Interesting. I was wondering just the other day why the contents of my source files didn't seem to be indexed, even though the indexing rules from windows search does include my development root. I had to use WinGrep to find what I was looking for.
>
> Should I file an issue? If not, will someone else?
>
> *
>
> I am not familiar with the code responsible for this, but a little browsing
> 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 that this
> would actually be a good solution.
>
> *
>
> (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 an issue
> filed in the Subversion issue tracker, or been fixed. Apologies if it has and I've
> missed it.)
>
> (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.)
>
> (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.)
>
> --
> Gareth McCaughan
Received on 2014-03-10 16:03:38 CET