[
https://issues.apache.org/jira/browse/SVN-4478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Zhakov updated SVN-4478:
-----------------------------
Description:
(I've seen this on Windows 7 with svn 1.7.5 and on Windows 8 with svn 1.8.3,
but I believe the problem affects every version of Subversion from 1.7 onwards.
I have no idea whether P3 is right; I'm just accepting the default and it
surely isn't my job to set priorities anyway.)
It appears that files checked out using Subversion (1.7 onwards) are marked as
not indexable by Windows search. I *think* the way in which this happens is as
follows:
When the WC is created:
# .svn directory is created, and marked as hidden and not indexable.
# .svn/tmp directory is created, and inherits that not-indexable property. (Or
maybe it's given it explicitly; I haven't checked.)
On checkout:
# Temporary file is created under .svn, and accordingly gets its not-indexable
flag set.
# 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.
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}} (in
libsvn_subr/stream.c; 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.
Original issue reported by *gareth_mccaughan*
was:
{noformat:nopanel=true}
(I've seen this on Windows 7 with svn 1.7.5 and on Windows 8 with svn 1.8.3, but
I believe the problem affects every version of Subversion from 1.7 onwards. I
have no idea whether P3 is right; I'm just accepting the default and it surely
isn't my job to set priorities anyway.)
It appears that files checked out using Subversion (1.7 onwards) are marked as
not indexable by Windows search. I *think* the way in which this happens is 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.)
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 (in
libsvn_subr/stream.c; 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.
{noformat}
Original issue reported by *gareth_mccaughan*
> Checked-out files are not indexed by Windows Search
> ---------------------------------------------------
>
> Key: SVN-4478
> URL: https://issues.apache.org/jira/browse/SVN-4478
> Project: Subversion
> Issue Type: Bug
> Components: libsvn_wc
> Affects Versions: 1.8.x
> Environment: Windows 7
> Reporter: Subversion Importer
> Fix For: ---
>
>
> (I've seen this on Windows 7 with svn 1.7.5 and on Windows 8 with svn 1.8.3,
> but I believe the problem affects every version of Subversion from 1.7
> onwards. I have no idea whether P3 is right; I'm just accepting the default
> and it surely isn't my job to set priorities anyway.)
> It appears that files checked out using Subversion (1.7 onwards) are marked
> as not indexable by Windows search. I *think* the way in which this happens
> is as follows:
> When the WC is created:
> # .svn directory is created, and marked as hidden and not indexable.
> # .svn/tmp directory is created, and inherits that not-indexable property.
> (Or maybe it's given it explicitly; I haven't checked.)
> On checkout:
> # Temporary file is created under .svn, and accordingly gets its
> not-indexable flag set.
> # 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.
> 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}} (in
> libsvn_subr/stream.c; 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.
> Original issue reported by *gareth_mccaughan*
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
