Having a StorageFolder object and trying to create a folder with a name that contains a colon somewhere inside (not at the beginning or the end) results in a COM error with HRESULT 80004005 (HRESULT E_FAIL).
Example:
await ApplicationData.Current.TemporaryFolder.CreateFolderAsync("abc:xyz",
CreationCollisionOption.OpenIfExists);
If the colon is at the beginning ot at the end I get a HRESULT 8007007b with the message "The filename, directory name, or volume label syntax is incorrect". That's fine.
I checked with other invalid chars but only a colon leads to E_FAIL.
This may be a problem if the user enters the folder name. Workaround is of course to simply check for a colon in the filename.
Does anyone know a possible reason for the E_FAIL error? I assume that COM thinks the foldername starts with an URI but can of course not figure out what kind of URI it is.
Well, COM's infamous error reporting is back with a vengeance. We've gotten spoiled from years of .NET's excellent and informative exceptions but that rug got pulled by WinRT. COM is the underlying interop mechanism and HRESULTs are the way errors get reported.
E_FAIL is the canonical error code, the only descriptive text you can get with that is "Unspecified error". Which is accurate, the Microsoft programmer that handled that code could not or did not want to produce a more descriptive error. Another great doozy is E_UNEXPECTED, it translates to "Catastrophic failure". The term "catastrophic" really refers to the value of the error message if you ever get it.
Speculating somewhat, the "abc:xyz" path string is actually valid. It refers to an alternate data stream named "xyz", stored in file "abc". So checking the path string isn't going to raise a stink, at first. You are however creating a folder by that name, not a file. A folder cannot have an alternate data stream. Apparently this is discovered very late, too late to still produce a more accurate error code. It should have produced a Windows error and they are wrapped appropriately in a HRESULT by or-ing it with 0x8007000 but that wasn't done for unguessable reasons.
No way to send feedback about this, the Windows group doesn't have the equivalent of DevDiv's connect.microsoft.com. Good thing you know what caused the error.
