I have a simple program. It runs .NET 4.5 and is built in Visual Studio 2013.
D:\\MyDir is full of .xlsx files and no .xls files. When I run the program on Windows 8.1 x64, the filter for *.xls returns no results. When I run the same program, with the same .NET version on Windows 7 x86, the *.xls filter returns the same results as the *.xlsx filter.
The test folders on both systems definitely contain the same data.
Am I missing something, or is this a bug in .NET and/or Windows?
The respective code:
using System;
using System.Collections.Generic;
using System.IO;
using System.Linq;
using System.Text;
using System.Threading;
using System.Threading.Tasks;
namespace throw_test
{
static class Program
{
static void Main()
{
int fileCount1 = Directory.GetFiles("D:\\MyDir", "*.xlsx").Length;
int fileCount2 = Directory.GetFiles("D:\\MyDir", "*.xls").Length;
Console.WriteLine("File Count 1: " + fileCount1);
Console.WriteLine("File Count 2: " + fileCount2);
Console.Read();
}
}
}
Edit 1
When I navigate to the directory using the command prompt in Windows 8.1 x64:
dir *.xlsx returns all files as expecteddir *.xls returns 'File Not Found'
Windows 7 returns the expected files on both of the above commands.
My guess is that .NET uses this command under the hood, thus the above results?
Your Windows 7 behavior is by design. From the documentation on the GetFiles() method (see the first note below the "Remarks" section):
When using the asterisk wildcard character in a searchPattern, such as "*.txt", the matching behavior when the extension is exactly three characters long is different than when the extension is more or less than three characters long. A searchPattern with a file extension of exactly three characters returns files having an extension of three or more characters, where the first three characters match the file extension specified in the searchPattern. A searchPattern with a file extension of one, two, or more than three characters returns only files having extensions of exactly that length that match the file extension specified in the searchPattern.
The Windows 8.1 behavior is a not reproducible for me. I just ran a test on my Windows 8.1 x64 machine, and it matched the expected Windows 7 behavior. I would check that the current folder on the machine is correct.
I can also get the same results just by opening up a command prompt, navigating to the appropriate directory, and typing dir *.xls. I expect that both the GetFiles() function and the command prompt will pass the search pattern into the same low-level operating system function.
It's talking about some different issues, but this post is also worth a read:
http://blogs.msdn.com/b/oldnewthing/archive/2007/12/17/6785519.aspx
I tried on my machine with *.xls and all xlsx files are returned, just as described by MDSN.
I have Visual Studio 2013, built as Debug/Release Any CPU on .NET 4.5, and run on Win 8.1 X64 against NTFS/FAT32 partition, should cover your environment. Do you have anything else special?
EDIT
According to this question, you may have disabled 8.3 naming on your Win 8.1 System by running:
fsutil behavior set disable8dot3
You can query the current status by running
fsutil behavior query disable8dot3 <VolumePath>
On my machine it returns default setting like:
The volume state is: 0 (8dot3 name creation is enabled).
The registry state is: 2 (Per volume setting - the default).
Based on the above two settings, 8dot3 name creation is enabled on c:
