Bad LocalPath on IDocumentStorageItem

Discussions concerning general integration topics.

Moderator: Phil Barton

Post Reply
muhsmann
Posts: 54
Joined: Thu Jan 15, 2009 5:41 pm

Bad LocalPath on IDocumentStorageItem

Post by muhsmann »

Hello,
I ran into a serious issue in our production environment when using the IDocumentStorageItem passed into my implementation of IDocumentStorage.SaveDocument().
The IDocumentStorageItem passed to my method seems to have a production stopping issue in the OriginalLocation System.Uri member of the object.
The path the user select to add the document was 'G:\CO_Prestige\FANNIE MAE AND LITTON FILES\3245 Milwaukee St #10\FNMA Wavier.doc'

When I was developing I assumed that what was passed to me would be complete URI so I used the LocalPath of the OriginalLocation to store the document. But when we went into producion yesterday our users were experiencing errors during the save document portion. I trapped enough information in my log file to find the LocalPath has a value of 'G:\CO_Prestige\FANNIE MAE AND LITTON FILES\3245 Milwaukee St' which is incomplete so my SaveDocument method fails because '3245 Milwakee St is not a file'. When I wrote a test app that creates a System.Uri off the same path the LocalPath is complete.
Not sure what's going on and I had to pretty much hack in using OriginalString for Path.GetFullPath() method to read past 'file:////' if it was there.
I have a screen shot of QuickWatch of IDocumentStorageItem passed to my method if that's of any interest - apparently its too big to upload.
Mark McKenna

Re: Bad LocalPath on IDocumentStorageItem

Post by Mark McKenna »

I believe the octothorpe character in the local file path is causing your problem. A Uri recognizes that character as the start of a Fragment (e.g. the Fragment portion of http://www.softprocorp.com/query.php#test would be "test"), and as such I believe Select is ignoring it when building out the local path from which it tries to access the source file for uploading. You could verify this by modifying your source file path and retrying; assuming this turns out to be the culprit, you should be OK if your local file paths avoided characters such as # and ? (characters that are meaningful within the context of a URI, even if they're valid file system characters). I have entered a work item on our end to address this - thanks for bringing it to our attention.
muhsmann
Posts: 54
Joined: Thu Jan 15, 2009 5:41 pm

Re: Bad LocalPath on IDocumentStorageItem

Post by muhsmann »

Mark,
I agree w/ you the # character is not being handled correctly and ultimately causing the issue. I cannot simply avoid using the character because in our production environment it means something. Since the character is legal in folder names I don't have much of an agrument. I'm curious when I construct a System.Uri using the same path all is as expected and not so w/ the System.Uri passed to my SaveDocument method? This issue caused a shutdown in our production environment so I was forced to find an immediate solution. When I construct the path (Path.GetFullPath(...)) to pass to the document storage application we use I found the only consistent member of the passed Uri was OriginalLocation.OriginalString - which if the 'file:////' exists I have to remove it before pass it to Path.GetFullPath().
I'm also wondering why use Uri in this situation?
Mark McKenna

Re: Bad LocalPath on IDocumentStorageItem

Post by Mark McKenna »

I missed the fact that you're using your own IDocumentStorage implementation, which will allow you to work around the problem that exists with our default storage implementation. Our implementation, and apparently yours as well, uses the Uri to reconstruct the original file path location in order to find the source document to upload. When the Uri is constructed, the # character is causing the LocalPath property to be returned truncated at that fragment location. We can't find the file and so the save fails.
In your case, as you've discovered, you should be able to access the OriginalString property of the Uri and remove the preceding file://// to obtain the full original file path, which essentially reverses the string formatting we used to create the Uri in the first place.
I believe the real issue, right or wrong, is with the Uri class itself and is related to (not) escaping the octothorpe:

Code: Select all

string test = @"C:\Test #1\test.doc";
Uri uri = new Uri( String.Format( "file:////{0}", test ) );
// uri.LocalPath is now "C:\Test "
Post Reply