Base types, Collections, Diagnostics, IO, RegEx…
You might start noticing that in Whidbey Beta2, IO exceptions are handing out full qualified path which was previously regarded as secure information. Well, don’t be alarmed. This information is still secure and let me explain how.
IO classes often take in relative path (for ex, DirectoryInfo) but when you call some methods on them they often operate on the normalized FullPath (for ex, DirectoryInfo.CreateDirectory which calls Directory.Create with FullPath under the hood), if we encounter an exception in this case (i.e, inside of Directory.Create), we need to somehow pass on the user visible path and make sure that we don’t accidentally reveal the FullPath information. You can see how easily this becomes unmanageable. Even if we could maintain discipline and pass on the original path information around though out the IO namespace, this solution doesn’t scale well for APIs that wrap IO functionality outside of BCL.
So the most obvious way to fix this would be to simply do a demand for path discovery before throwing an exception that includes a path. If the demand succeeds, we use the available path at that stage (Note: this may or may not always be fully qualified). If the demand fails, we will use the file name (Path.GetFileName(path)) from the available path but not directory names. If the name ends in a \, we’ll assume it is a directory, and therefore hand back either “” or something like “<no path discovery permission for this path>”.
While it is great to hand out the FullPath information in exception messages for trusted apps, it is quite disastrous to hand out only FileName for partially trusted apps where we could be possibly revealing more relative path information. In short, back tracing to the file from the exception message is bit more difficult now for semi trusted apps.
To help with the debugging scenarios & hosting scenarios where a fully trusted host is displaying an IOException from a partially trusted assembly, we will now be storing the full path in IOException object as a private field. This should help you debug problems without losing too many capabilities that you currently have. Ideally, we would reveal this information as an overload of ToString or a public property on IOException but by the time we could evaluate PathDiscovery the original stack has been unwound. Also, this field will not be serialized so that we don’t introduce any versioning problem as well as for the inability to evaluate PathDiscovery against the right callstack as stated above.