views:

32

answers:

1

I've got some old legacy code that I'm maintaining (please forgive the naming, this was written by a non programmer and the application is not important enough to be rewritten):

Dim Path3 As String
Path3 = "C:\Inetpub\wwwroot\uscgcrc\rsa\RSADocuments\IRBCorrespondenceToPI\"

Dim dirInfo3 As New DirectoryInfo(Path3)

Dim FileContainer3 As FileInfo() = dirInfo3.GetFiles("1370*.*")

Dim FileOnly3 As FileInfo
For Each FileOnly3 In FileContainer3
    Response.Write("<tr style='border: 1px solid #000000;'><td>")
    Response.Write("<a href='https://www.uscgcrc.org/rsa/RSADocuments/IRBCorrespondenceToPI/" + FileOnly3.Name + "'>" + FileOnly3.Name + "</a><br>")
    Response.Write("</td></tr>")
Next FileOnly3

The files returned are:
1302_IRBCorr_04-27-10.pdf
1302_IRBCorr_06-10-10.pdf
1309_IRBCorr_04-08-10.pdf
1309_IRBCorr_04-02-10.pdf
1370_1000485_IRB-Accept_with_Contingencies_Letter_09-23-10.pdf

As you can see the files returned do not all match the search pattern that I pass to GetFiles. This code works for every other search pattern like ("1369*.*") etc.

The files that it pulls up seem to have nothing in common, but those 5 files are pulled up every time for the search pattern "1370*.*"

What the heck could be going on here?

+1  A: 

Since these are long filenames maybe you are running into a wrinkle in this API where it matches against both the full filename and the 8.3 filename. From the MSDN docs:

Because this method checks against file names with both the 8.3 file name format and the long file name format, a search pattern similar to "*1*.txt" may return unexpected file names. For example, using a search pattern of "*1*.txt" will return "longfilename.txt" because the equivalent 8.3 file name format would be "longf~1.txt".

You can filter the results after the fact by by checking them and ignoring false positives. Sorry, this is C# code.

string initial = "1370";
foreach (FileInfo match in FileContainer3)
{
  if (match.Name.Substring(initial.Length) != initial)
  {
    continue;
  }
}
Steve Townsend
I've checked, I don't think that's the problem.
Yuriy Faktorovich
@Yuriy - puzzling - is there anything else in the returned FileInfo false positives that might cause this anomaly? Have you tried just using "1370*" as the pattern? Can you reproduce this in a minimally small C# app running against that directory?
Steve Townsend
@Steve, actually I can't reproduce his bug, and I think he is executing something he doesn't think he is. But the long file name shouldn't be an issue because he doesn't have a \* before the 1370.
Yuriy Faktorovich
Are you both running the same .Net fwk revision? Sounds like you have a good case to treat this as a bug in the app from here on.
Steve Townsend
I don't think it is that either but who knows. Ask him to use dir /x on the command prompt to verify.
Hans Passant
Wow! Stack overflow comes through again. dir /x confirmed that for strange reason the files called 1302_ had a 8.3 file name of 1370_. Don't know how this ever happened. I do know C# as well as my VB, so I should have no problem implementing this solution. Thanks guys.
Praveen Angyan
@Praveen - those 8.3 file names - MSDOS really is the gift that keeps on giving, 20 years on.
Steve Townsend