Home > SharePoint, SharePoint 2010 > SharePoint 2010 Bug: “Move and Leave a Link” to a document in a Records Centre allows duplicate filename upload and can overwrite existing links

SharePoint 2010 Bug: “Move and Leave a Link” to a document in a Records Centre allows duplicate filename upload and can overwrite existing links


Back in September 2011 we were setting up a Records Management system for a client and configured a Send To Connection to enable a document to be sent to the Records Centre, leaving a link behind in the document library using the “Move and Leave a Link” Send To action.

This all seemed to work fine until we started to notice during testing that occasionally some of the links in the document library to the records in the Records Centre no longer pointed to the original records but instead to new records. Further investigation revealed that the problem occurs when uploading a file with the same filename as a previous file which had been sent to the Records Centre previously. When files are received by the Records Centre, if a record already exists with the same filename, the newly received file gets renamed with a series of characters appended to the filename, ensuring the new record is unique and does not overwrite an existing record. However guarantee of uniqueness does not happen to the links that are left behind in the document library where the document was originally sent from.

The scenario is not quite as straight-forward as this otherwise I am sure this would have been picked up and resolved much sooner. The problem actually only occurs on the 3rd attempt to send a document with the same filename to the Records Centre. Here are the full steps to recreate the problem, assuming you already have a site containing your document library and a fully configured Records Centre with a file plan and Content Organiser Rules:

  1. Configure the Send To Connections for your web application containing the document library (Central Admin > General Application Settings > Configure Send To Connections) to “Allow manual submission from the Send To menu” and set the Send To action to “Move and Leave a Link” then press the button to Add Connection.
  2. Upload a document (doc1.docx) to the document library.
  3. Send this document to the Records Centre using the new Send To action. The document is moved to the Records Centre and becomes a record, while a link is left behind in its’ place in the document library, with the filename doc1.aspx. Note the file extension of the link indicates this link is an ASPX page while the rest of the filename matches the original document filename. This file extension is the significant factor in the problem.
  4. Upload the same document again to the same document library, or a different document but with the same name as the original document (doc1.docx). Normally SharePoint would complain and prevent you from uploading files with the same name as existing files in a document library, however as the file extension is different to the link, SharePoint allows the document to be uploaded to the document library. There are now 2 files in the document library, doc1.aspx and doc1.docx.
  5. Send the new document to the Records Centre as before. The document is moved to the Records Centre and becomes a record but because doc1.docx already exists in the Records Centre, it is renamed with a series of characters appended to the filename ensuring the filename is unique and does not overwrite the existing record A link is left behind in its’ place in the document library, however because a link already exists with the filename doc1.aspx, the new link is instead created as doc1.docx.aspx, so not overwriting the existing link in the document library. There are now 2 files in the document library, this time with the filenames doc1.aspx and doc1.docx.aspx, each linking to the appropriate records in the Records Centre.
  6. Upload the same document again or another document with the same name for the third time to the same document library (doc1.docx). Again SharePoint does not complain because there is still no file in the document library called doc1.docx so it is allowed.
  7. Send the new document to the Records Centre again for the third time. Again the document is moved to the Records Centre and is given a unique filename by appending a series of characters to the filename. A link is left behind in its’ place in the document library, however because a link already exists with the filename doc1.aspx, the new link is instead created as doc1.docx.aspx, so not overwriting the first link in the document library. However it does not check for the existence of the second link and proceeds to overwrite the link doc1.docx.aspx! Where we might expect now to have three links in the document library pointing to the three records in the Records Centre, we now have 2 links, the first link pointing to the first record, and the second link pointing to the third record, where the second link was overwritten.
  8. And so it goes on with each subsequent document using the same filename, where the last link is always overwritten with the new link, and users of the document library lose visibility of those documents that were sent to the Records Centre unless they go looking for them directly in the Records Centre file plan…

I submitted this bug to Microsoft initially in September 2011 and after review, the following resolution was suggested:

Unfortunately due to broad (and possibly negative) impact that a change of this functionality may have on other customers we cannot at this moment change this functionality. We suggested you to create a custom event receiver that would handle the ItemAdding and ItemUpdating event, check the name of the file and if filename.aspx or filename.ext.aspx exists in the library already, do not allow the Upload/Change of the file (cancel the event).

We felt that creating such an event receiver would not be a great user experience without being able to properly inform the user why a document upload fails, so we parked it for a while.

On 30th November, I was contacted by Microsoft about this issue:

We reconsidered the issue and a decision has been made to take this fix! While this is not something I can guarantee 100%, I can tell you that we are working on it already. Our SharePoint Product Group is planning to release the code change together with the February 2012 Cumulative Update.  Again this is not a hard deadline – I will monitor the progress and send you updates whenever I have some more news.

The details of the potential fix then followed on 1st December:

At the moment it looks like the fix will allow to append a new unique string to every version of the link – this way it will not overwrite the older ones (and therefore make them visually disappear). As I believe this should be exactly the solution you expected, right? Can you send me a shorter confirmation on this?

Optionally (by setting a special property) it should also give a chance to say to SharePoint: please overwrite the link every time I send the same file – this would be a solution for the other scenario that I mentioned to you (when the file gets overwritten in the target).

Again – it is still being developed so I can’t give you any warrantees – but everything seems to be going in this direction.

This solution sounds like it should resolve the problem, while also not preventing others from taking advantage of this behaviour (by setting a special property).

I was expecting to hear progress early in January but so far have not heard anything more, and right now the Escallation Engineer is on vacation, so we’ll have to wait and see whether it makes it into the February 2012 Cumulative Update. I will post updates to this article when I get any further information.

For information, the original Microsoft case number is REG:111091449565708. However due to change in the company’s support contract at the end of 2011, this was closed and was due to be reopened under the new support contract in January 2012.

Update 13 Feb 2012: Microsoft have confirmed that this fix has been implemented and tested, and is planned for release in the February 2012 Cumulative Update for SharePoint 2010 at the end of the month. The new ticket covering this defect is 112021054539463.

Update 8 March 2012: The February 2012 Cumulative Update was released yesterday and I am informed that it contains a fix to this problem, however it is an opt-in fix, meaning that after installing the CU we have to set a property on the web application for it to take effect. Here is the relevant part of the message from Microsoft Support explaining how to opt-in for this fix and the rationale.

There is one very important thing about your fix that I need to share with you. If you remember our discussions some months ago, I told you that this is a tricky fix, cause some of our customers expect a new link to get created every time (you for example), some expect only one link (cause the files get overwritten at the destination) and there are also some that are happy with the current (pre-FebCU) behaviour. That was the main reason why we very so reluctant to change the behaviour in the first place.

The final decision was that we made this to an ‘opt-in’ fix. Just installing the FebCU will not change the behaviour at all (so please don’t panic after the first tests ). In order to enable the functionality you require, you need to set a new property on the web application level – the property is called ‘OverwriteFileLink’. By default the property does not exist and the behaviour is the same as in the RTM version of SharePoint 2010. Setting this property on a Web Application to ‘False’ will cause the behaviour to be exactly like you expect – a new link will be created every time. Setting it to ‘True’ on the other hand will cause only 1 link to be created.

Below you can see a sample SharePoint PowerShell script that should help you set the property. Please be sure to run it after installing the FebCU and before testing the functionality.

$OverwriteKey = "OverwriteFileLink"
$WebApp = Get-SPWebApplication your_web_app_name
$WebApp.Properties[$OverwriteKey] = $false
$WebApp.Update()
Advertisements
  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: