Second Life of a Hungarian SharePoint Geek

July 27, 2018

A specific case of "The file name you specified is not valid or too long" error in SharePoint Explorer view

Filed under: SP 2013 — Tags: — Peter Holpar @ 21:07

Recently I found a document library in one of our SharePoint 2013 environments, that produced an odd behavior. I describe the symptoms and the solution below.

Symptoms

Problem with uploading file into a document library

I opened the Site Assets document library in a web site of a SharePoint 2013 installation (I don’t think the error is specific to this special kind of document libraries or SharePoint version, but I document it for the sake of completeness), and created a folder called ‘js’. The folder was created without any problem. I wanted to copy a .js file into the folder, but received the error message “The file name you specified is not valid or too long”. There was of course no problem with the length of the file nor with the name itself. I was simply not able to upload any file into that specific library, independent of the folder or the file name and extension. See below an error message for a text file. Clicking “Try Again” was unsuccessful.

image

I was able to upload files into other document libraries of the same site, as well as into libraries in other sites, so I assumed the problem is related to the library itself, but to be sure, I restarted first the WebClient service in Windows, then the whole Explorer process (including the desktop), finally the operating system itself, but all of them without any result (except losing lot of time).

I observed, however, that the file was uploaded despite of the error message. It appeared both in Windows Explorer as well as in the browser (I was able to open it!), at least till I clicked “Cancel” in the dialog box above. Then the file got deleted and disappeared, as it would have not been uploaded at all. Very strange.

I created a network trace using Fiddler to investigate the steps of the process. I include the HTTP response codes and optionally further information in brackets, unsuccessful steps are written in red:

PROPFIND /YourSite/SiteAssets (207)
PROPFIND / (207)
PROPFIND /YourSite/SiteAssets/YourFile.txt (404)
PROPFIND /YourSite/SiteAssets (207)
PUT /YourSite/SiteAssets/YourFile.txt (In the request we send the X-MSDAVEXTLockTimeout header with a value of Second-3600 and do not include the file in the request body, it indicates we acquire only a lock. The response includes these headers: X-MSDAVEXTLockTimeout: Second-3600; Lock-Token: opaquelocktoken:{D126A8C0-4DA2-4BD1-919F-566A6B68B507}20180725T072618Z; X-MS-File-Checked-Out: 1. The HTTP response code is 201)
HEAD /YourSite/SiteAssets/YourFile.txt (200)
PUT /YourSite/SiteAssets/YourFile.txt We include the lock token we acquired earlier: Lock-Token: <opaquelocktoken:{D126A8C0-4DA2-4BD1-919F-566A6B68B507}20180725T072618Z>, another header X-MSDAVEXT: PROPPATCH and the file to be uploaded in the request body. The HTTP response code is 500, the response includes the header X-MSDAVEXT_Error: 589829; The%20URL%20%27SiteAssets%2fYourFile%2etxt%27%20is%20invalid%2e%20%20It%20may%20refer%20to%20a%20nonexistent%20file%20or%20folder%2c%20or%20refer%20to%20a%20valid%20file%20or%20folder%20that%20is%20not%20in%20the%20current%20Web%2e)
HEAD /YourSite/SiteAssets/YourFile.txt (200)
PUT /YourSite/SiteAssets/YourFile.txt (It’s not clear what happens in this step, we try to upload the file again, but with another headers this time, like If: (<opaquelocktoken:{D126A8C0-4DA2-4BD1-919F-566A6B68B507}20180725T072618Z>) and there is no X-MSDAVEXT. The file to be uploaded is included again in the request body. The HTTP response code is 500, the response includes the header X-MSDAVEXT_Error value as earlier.)
PROPFIND /YourSite/SiteAssets (207)
PROPFIND /YourSite/SiteAssets/desktop.ini HTTP/1.1 (404)

After clicking “Cancel”:

HEAD /YourSite/SiteAssets/YourFile.txt (200)
PUT /YourSite/SiteAssets/YourFile.txt HTTP/1.1 (This time we send only a DAV property update request, the file is not included in the request body. The HTTP response code is 500, the response includes the header X-MSDAVEXT_Error value as earlier.)
HEAD /YourSite/SiteAssets/YourFile.txt (200)
PUT /YourSite/SiteAssets/YourFile.txt HTTP/1.1 (Another put request with the header If: (<opaquelocktoken:{D126A8C0-4DA2-4BD1-919F-566A6B68B507}20180725T072618Z>) but without the file in the request body. The HTTP response code is again 500, the response includes the header X-MSDAVEXT_Error value as earlier.)
UNLOCK http://YourServer/YourSite/SiteAssets/MailAdresses.txt (we try to unlock the file, including the header Lock-Token: <opaquelocktoken:{D126A8C0-4DA2-4BD1-919F-566A6B68B507}20180725T072618Z>. The HTTP response code is 412)

PROPFIND /YourSite/SiteAssets/YourFile.txt (207)
DELETE http://YourServer/YourSite/SiteAssets/YourFile.txt (We delete the file. The HTTP response code is 204)

In the corresponding ULS log entries I found these lines (all entry with Area: SharePoint Foundation, Category: Database; Level: High):

System.Data.SqlClient.SqlException (0x80131904): Parameter ‘@tp_Version’ was supplied multiple times. at System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection, Action`1 wrapCloseInAction) at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj, Boolean callerHasConnectionLock, Boolean asyncClose) at System.Data.SqlClient.TdsParser.TryRun(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj, Boolean& dataReady) at System.Data.SqlClient.SqlDataReader.TryHasMoreRows(Boolean& moreRows) at System.Data.SqlClient.SqlDataReader.TryReadInternal(Boolean setTimeout, Boolean& more) at System.Data.SqlClient.SqlDataRea… …der.TryNextResult(Boolean& more) at System.Data.SqlClient.SqlDataReader.NextResult() at Microsoft.SharePoint.SPSqlClient.ExecuteQueryInternal(Boolean retryfordeadlock) at Microsoft.SharePoint.SPSqlClient.ExecuteQuery(Boolean retryfordeadlock) ClientConnectionId:0ed39f0d-b333-43fd-90e3-421a19b57441 Error Number:8143,State:1,Class:16 ExecuteQuery failed with original error 0x80131904 SQL error code from last error 8143 – Parameter ‘@tp_Version’ was supplied multiple times.

Creating new files into a document library

It is the same library as earlier, but instead of copying a file into it, I have tried to create a new file this time. I’ve selected New / Text Document in Windows Explorer, have renamed it to test.txt, opened it in Notepad, added some content and saved it. The file was saved, and was available in Windows Explorer as well in the browser, but a warning appeared in the low right corner of the desktop, saying:

Delayed Write Failed
Windows was unable to save all the data for the file \YourServer\YourSite\SiteAssets\test.txt. The data has been lost. This error may be caused by a failure of your computer hardware or network connection. Please try to save this file elsewhere.

image

I found a page about that issue but it said really nothing, and was not right either, as the file was saved in my case, despite of the warning.

I’ve found an entry in Event Viewer (Windows Logs / Application having Source: WebClient; Level: Warning) that probably belongs to the error above:

The description for Event ID 14903 from source WebClient cannot be found. Either the component that raises this event is not installed on your local computer or the installation is corrupted. You can install or repair the component on the local computer.
If the event originated on another computer, the display information had to be saved with the event.
The following information was included with the event:
\YourServer\YourSite\SiteAssets\New Text Document.txt
123

It wasn’t really helpful too.

The solution

What really helped was the ULS log I’ve included above, especially the part:

(0x80131904): Parameter ‘@tp_Version’ was supplied multiple times.

I was sure I hade already the same or a very similar issue (eventually with another parameter name), yet with SharePoint 2010, and at that time I verified the statement with SQL Profiler and found, that the parameter is sent really twice in the query. Unfortunately (or fortunately?), it was a long time ago, and I have not remembered the solution. But a quick search on the web helped, and I found this forum entry.

Although related to an other field (Author), the answer states, that a similar problem was caused by a field schema corruption. So I decided to check the schema of the field that belongs to the tp_Version parameter (that is the owshiddenversion field):

$web = Get-SPWeb http://YourServer/YourSite
$list = $web.Lists[‘Site Assets’]
$list.Fields.InternalName
$list.Fields[‘owshiddenversion’]
$versionField = $list.Fields[‘owshiddenversion’]
$versionField.SchemaXml

The result was:

<Field ID="{d4e44a66-ee3a-4d02-88c9-4ec5ff3f4cd5}" Name="owshiddenversion" SourceID="http://schemas.microsoft.com/sharepoint/v3" StaticName="owshiddenversion" Group="_Hidden" ColName="tp_Version" RowOrdinal="0" Hidden="TRUE" ReadOnly="TRUE" Type="Integer" SetAs="owshiddenversion" DisplayName="owshiddenversion" Sealed="FALSE" Version="1" />

I then compared the results with the field schema of another document library, where the upload works as it should:

$list = $web.Lists[‘Documents’]
$versionField = $list.Fields[‘owshiddenversion’]
$versionField.SchemaXml

The result was this time:

<Field ID="{d4e44a66-ee3a-4d02-88c9-4ec5ff3f4cd5}" ColName="tp_Version" RowOrdinal="0" Hidden="TRUE" ReadOnly="TRUE" Type="Integer" SetAs="owshiddenversion" Name="owshiddenversion" DisplayName="owshiddenversion" SourceID="http://schemas.microsoft.com/sharepoint/v3" StaticName="owshiddenversion" FromBaseType="TRUE"/>

You can see, that – exactly as the forum answer suggests – the attribute FromBaseType="TRUE" is missing from the schema XML. To fix the difference, I run this script on the corrupted library:

$xml = [xml]$versionField.SchemaXmlWithResourceTokens
$xml.Field.SetAttribute(‘FromBaseType’,’TRUE’)
$versionField.SchemaXml = $xml.OuterXml
$versionField.Update()

By running the script the difference in the field schema  XML was fixed, and there was no more problem with copying to and creating files in the library.

Advertisements

Leave a Comment »

No comments yet.

RSS feed for comments on this post. TrackBack URI

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

Blog at WordPress.com.

%d bloggers like this: