Saturday, April 07, 2012 3:37 PM
When I upload an audio file using "UploadAsync" (Managed APIs, v5.0, Windows Phone) with a "fileName" parameter that contains spaces, the file gets created but the resulting name that's displayed on SkyDrive is URL-encoded. For example, the following call:
_client.UploadAsync(FOLDER_ID, "a filename with spaces.wav", fileStream);
... results in the file being created with a name of "a%20filename%20with%20spaces.wav". This URL-encoded name becomes the display name for both skydrive.live.com and any subsequent API use. I've tried changing the extension to ".txt" and the same encoding of spaces occurs. I haven't tried yet with other non-alpha characters, but I suspect I would run into similar issues.
How can I prevent the filename from being encoded when using the managed APIs? I read a couple of recent posts detailing problems with accessing files with spaces, but I haven't seen this problem reported yet. Maybe a better question: Should I care? In other words, is this a Live SDK issue (the SDK doesn't report the filename correctly to SkyDrive) or a SkyDrive issue (SkyDrive doesn't correctly interpret the filename given by the Live SDK)? If the former, I have to do something on my end to mitigate the issue (such as stripping the spaces or informing the user of this limitation, or upgrading to a newer version of the SDK that would fix the issue. ETA?). If the latter, then I can just let my app export the file as is, and hope for a SkyDrive fix in the near future that will remove the encoding in the display name.
- Edited by Antoine Cloutier Saturday, April 07, 2012 3:38 PM
Monday, April 09, 2012 6:47 PMModerator
Hi Antoine, I'm checking on whether this is related to this:
or if there's something specific that needs to be done in order to get file names containing spaces to work.
Monday, April 09, 2012 8:13 PM
This bug was introduced in the process of trying to fix file uploads that have '#' and '%' characters in the file name. We already have a fix prepared and are in process of getting that fix out. I'll repost here once it should be fixed.
Sorry for the inconvenience. Thank you for reporting this issue,
- Marked As Answer by Antoine Cloutier Tuesday, April 10, 2012 11:18 PM
Tuesday, April 10, 2012 11:18 PM
Thanks for the information. Am I right in assuming that whatever the fix for this specific issue, it won't require a newer version of the Live SDK assemblies? The reason I'm asking this is because I expect to be publishing a newer version of my Windows Phone app this week (with the 5.0 Live SDK binaries). The "filename with spaces" issue is not a show stopper (the functionality is still working, albeit in a non user-friendly way), but I'd consider waiting for newer binaries if they are required for the fix.
Wednesday, April 11, 2012 1:18 AM
Your hunch is absolutely correct. This fix is entirely a server-side fix and will not require any library/SDK update.
- Marked As Answer by Antoine Cloutier Wednesday, April 11, 2012 6:00 PM
Thursday, April 12, 2012 7:42 PM
It looks like the space issue is fixed now because I can no longer reproduce the problem. The fix came way faster than I had imagined!
Thanks to all involved.
Thursday, April 12, 2012 8:05 PMThe fix has not propagated to all of our servers but the fix is in fact on its way out. :-)
Tuesday, April 24, 2012 6:14 PM
As you may have noticed, this bug as reappeared. We had to remove the fix because a much larger bug had snuck out with that build. We've fixed it again internally and are working to get it back out as soon as we can.
I appologize for the inconvenience. I'll update this thread once it goes back out. I expect this to happen in roughly 1 week or less.
Wednesday, April 25, 2012 10:05 PMAlso waiting for this fix.
Thursday, April 26, 2012 11:22 PM
This should be fixed again. Please give it a shot and let us know if you continue to see any problems.
Friday, April 27, 2012 12:31 AMWorks for me. Thanks!