Reputation: 4862
I am mainly interested in the design decision behind this.
background information:
FileSystemInfo is base class to (and only to) FileInfo and DirectoryInfo.
Both classes implement GetAccessControl()
, returning a FileSecurity or DirectorySecurity object respectively.
FileSecurity
and DirectorySecurity
both derive from FileSystemSecurity - and again are the only classes to do so.
Neither FileSecurity
nor DirectorySecurity
seem to declare any methods or properties of their own - apart from constructors.
Yet still, FileSystemInfo
does not contain a public FileSystemSecurity GetAccessControl()
method.
Question:
Can anybody shed some light onto why FileSystemInfo
does not contain this method?
example code
public static void GrantFullControlToBuiltinUsers(this FileSystemInfo fileSystemInfo)
{
FileSystemSecurity acFile;
if(fileSystemInfo is DirectoryInfo)
acFile = ((DirectoryInfo) fileSystemInfo).GetAccessControl();
else
acFile = ((FileInfo)fileSystemInfo).GetAccessControl();
acFile.AddAccessRule(
new FileSystemAccessRule(GetAccountNameBuiltinUsers(),
FileSystemRights.FullControl,
AccessControlType.Allow));
if (fileSystemInfo is DirectoryInfo)
((DirectoryInfo)fileSystemInfo).SetAccessControl((DirectorySecurity)acFile);
else
((FileInfo)fileSystemInfo).SetAccessControl((FileSecurity)acFile);
}
The code is far from beautiful with all the (unnecessary) casts in it and I wondered why the library was designed in this way.
Upvotes: 1
Views: 557
Reputation: 14700
My guess is that they wanted to have the two GetAccessControl methods return the proper, concrete types - FileSecurity and DirectorySecurity, respectively. If they inherited from a common GetAccessControl() method, they would be forced to return FileSystemSecurity, and the user would have to cast it manually.
It's an aesthetic choice, mostly.
Upvotes: 2