3

We've got a problem in our search-driven document management system, and I'm running out of ideas.

A custom event receiver, on ItemUpdated() checks to see if the files metadata requires it to be moved to another library (in the same SPWeb). If so, it creates any required folders, moves it with SPFile.MoveTo(), then updates another bit of metadata with SPFile.Item.Update() and followed up with SPList.Update() (which may or may not be necessary).

Sometimes the event receiver fires immediately after the file is added (by a very complex timer job we would prefer not to re-write), but it is also run when changes are made to metadata by users.

The problem is that the search indexer will not pick up the changes until a full crawl is run. We run continuous crawls and are dependant on having up to date search results. Until now we've been running three extra full crawls each day, but as the volume of files grows this is becoming impractical.

How should we move the files so that an incremental crawl will find the changes?

P.s. This is an on-premise SP2013 farm.

Improve this question
2
  • Tyr, make sure the moved files are checked-in and published.
    – Naveen
    Commented Jun 17, 2015 at 10:40
  • @Naveen: the library in question doesn't use versioning, but they are definitely checked in.
    – Tyr
    Commented Jun 17, 2015 at 10:51

1 Answer 1

Reset to default
3
+50

I'm grasping at straws here, there isn't a lot of information on the topic about this. I did stumble upon a post that may give clues as to why it is happening and perhaps a work around:

SPFile.MoveTo(), at first glance, looks to be a very straightforward method where a file can be moved from one folder to another.

Trying to use it and have an alert triggered by your newly copied file? Forget it.

MoveTo() copies the binary to the target library as expected, but fails to recreate the item metadata (created, modified, users, dates, etc.) and will not trigger the alerts that your users set up for the target library.

To work around this problem, you can create your own method that uses the SPFileCollection.Add(), which allows you to specify metadata, as described here: (broken link ommitted).

http://sharepointers.blogspot.com/2009/01/spfilemoveto-not-triggering-alerts-in.html

If this is the case, then I can see why it wouldn't be found until a full crawl is run.

Improve this answer
2
  • Thank you, that looks like it might be the answer, however it throws up another problem. When previously using SPFileCollection.Add() in a content organiser ICustomRouter implementation, I was unable to get it to accept the modified and created times. There is an overload which takes parameters for them, but no matter what I did it would ignore their values and use the current time instead. We need to preserve at least the created time on the moved file, which SPFile.Move() does.
    – Tyr
    Commented Jun 18, 2015 at 9:35
  • Couldn't you update the values in another operation after it was moved in that case? Or try a SPFile.CopyTo(), since it is in the same web, then delete the source document?
    – Eric Alexander
    Commented Jun 18, 2015 at 12:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.