CODEWITHSUNDEEP
.netfile-extension
bubbleking
bubbleking

Reputation: 3601

DirectoryInfo.Extension - Why does this exist?

I just noticed that the DirectoryInfo class has the Extension property, inherited from FileSystemInfo. I am confused why this was made part of the base class instead of only being declared and implemented in the FileInfo class. That is, since directories don't have extensions, this seems to be a strange design decision.

Furthermore, I was just working with a DirectoryInfo instance and noticed the Extension property seemed rather arbitrary. It appeared to be the original name of the folder (not the current name), converted to lower case. For example, let's say I had a folder that was originally name MyCoolFolder. Later, I changed the name to MyGoodFolder. The DirectoryInfo.Extension property would, supposably, based on what I've seen, read .mycoolfolder. Why? What could be useful about having the Extension property on a DirectoryInfo, and what's useful about having the original name in lowercase?

Upvotes: 0

Views: 178

Answers (2)

MgSam
MgSam

Reputation: 12803

It seems to be valid to have a directory with an "extension". It is allowed both in the filesystem and .NET. In that context, I suppose the Extension property is behaving correctly. That said, I've never seen a directory with an extension, other than "hidden" directories that start with a period (.git, .vs, etc).

Example:

var dir = Directory.CreateDirectory(@"c:\temp.txt");
Console.WriteLine(dir.Exists); //True
Console.WriteLine(dir.Extension); //.txt

Also, I should point out the behavior the OP supposes about how Extension works is incorrect (not sure why they didn't just test...) Extension looks for a period and returns the period and everything after it. For a directory name without a period Extension will return an empty string.

Upvotes: 2

Łukasz Rozmej
Łukasz Rozmej

Reputation: 249

It is just a design flaw of this object hierarchy.

If you think this is bad look at (only left relevant code):

public abstract class Array : IList
{
  int IList.Add(object value)
  {
    throw new NotSupportedException(Environment.GetResourceString("NotSupported_FixedSizeCollection"));
  }
}

Just accept that .net framework designers make mistakes too and that mistake made in widely used API is very hard if not impossible to fix as backwards compatibility most often has higher priority.

Upvotes: 0

Related Questions