[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Subversion checked-out files not indexed in Windows search

From: Ivan Zhakov <ivan_at_visualsvn.com>
Date: Wed, 12 Mar 2014 17:58:28 +0400

On 10 March 2014 18:25, Gareth McCaughan
<Gareth.McCaughan_at_lightblueoptics.com> wrote:
> 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.
>
> 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.)
>
It looks like serious issue. Could you please file issue in Subversion
issue tracker:
http://subversion.tigris.org/issues

-- 
Ivan Zhakov
CTO | VisualSVN | http://www.visualsvn.com
Received on 2014-03-12 14:59:22 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.