6 Replies - 234 Views - Last Post: 28 June 2013 - 07:24 AM Rate Topic: -----

#1 ybadragon  Icon User is offline

  • D.I.C Addict
  • member icon

Reputation: 151
  • View blog
  • Posts: 968
  • Joined: 11-May 12

Wildcard Semi-Consistent Bug using FileInfo

Posted 28 June 2013 - 05:23 AM

Hi,

I've been having this problem using multiple wildcards while using FileInfo. first I'll show the code, then explain it. I have a workaround for the issue, I just want to know why the bug is happening, because I can't for the life of me figure it out.

  Private Sub cmbFileType_SelectedIndexChanged(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles cmbFileType.SelectedIndexChanged
    chooseItem(sender)
    Dim dirInfo As New DirectoryInfo(sNDrive & "DATA\Client\Output\" & cmbFileCode.Text & "\")
    ' for some reason this line returns incorrect filetypes
    'Dim files1 As FileInfo() = dirInfo.GetFiles("*" & fileType & "*.aes")
    Dim files As FileInfo() = dirInfo.GetFiles(cmbFileCode.Text & fileType & "*.aes")
    Dim dra As FileInfo = Nothing
    cmbFileName.Items.Clear()
    cmbFileName.Text = ""
    reset()
    For Each dra In files
      If Not cmbFileName.Items.Contains(Mid(dra.Name, 1, dra.Name.IndexOf("."))) And dra.Name.Contains("Page") Then
        cmbFileName.Items.Add((Mid(dra.Name, 1, dra.Name.IndexOf("."))))
      End If
    Next
  End Sub



So what the user does in this program is choose a Filecode which the program gets from "K:\DATA\Client\Output\" when the user chooses the filecode a list is populated for the filetype, which is found in the name of each file in the filecode directory the error only happens when the user chooses "F1" from the filetype section, and only from this filecode "DTI062501". If you look in the code at the 2nd commented line this returns incorrect data. It should return

DTI062501F1M_2-4_Pages.001.aes
DTI062501F1M_2-4_Pages.002.aes
DTI062501F1M_2-4_Pages.003.aes
DTI062501F1M_2-4_Pages.004.aes
DTI062501F1M_2-4_Pages.005.aes
DTI062501F1S_1_Page.005.aes

but for some reason it returns this

DTI062501FCM_2-4_Pages.012.aes
DTI062501F1M_2-4_Pages.001.aes
DTI062501F1M_2-4_Pages.002.aes
DTI062501F1M_2-4_Pages.003.aes
DTI062501F1M_2-4_Pages.004.aes
DTI062501F1M_2-4_Pages.005.aes
DTI062501F1S_1_Page.005.aes

as you can see, the first item in the list does not contain "F1" anywhere, nor does the filecode, and so I can't figure out why it would be returning this data. I've looked at this problem for 2 days now, and can't figure it out. If any of you have an idea as to why this would be happening, but only in this filecode, or need more information, please let me know.

Thanks :)/>

Is This A Good Question/Topic? 0
  • +

Replies To: Wildcard Semi-Consistent Bug using FileInfo

#2 ybadragon  Icon User is offline

  • D.I.C Addict
  • member icon

Reputation: 151
  • View blog
  • Posts: 968
  • Joined: 11-May 12

Re: Wildcard Semi-Consistent Bug using FileInfo

Posted 28 June 2013 - 05:29 AM

Another interesting thing is it is only returning the last file of filetype "FC" (the bad data) where as if it were messing up and getting all of the "FC" files in that directory, it would have returned 11 other "FC" files (hense the ".012" on the end of the file.)
Was This Post Helpful? 0
  • +
  • -

#3 lar3ry  Icon User is offline

  • Coding Geezer
  • member icon

Reputation: 310
  • View blog
  • Posts: 1,290
  • Joined: 12-September 12

Re: Wildcard Semi-Consistent Bug using FileInfo

Posted 28 June 2013 - 06:22 AM

View Postybadragon, on 28 June 2013 - 06:29 AM, said:

Another interesting thing is it is only returning the last file of filetype "FC" (the bad data) where as if it were messing up and getting all of the "FC" files in that directory, it would have returned 11 other "FC" files (hense the ".012" on the end of the file.)

I found an interesting note in the GetFiles docs. I can't quite tell if it's relevant to your problem, but here it is, just in case...

Quote

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".

Was This Post Helpful? 0
  • +
  • -

#4 ybadragon  Icon User is offline

  • D.I.C Addict
  • member icon

Reputation: 151
  • View blog
  • Posts: 968
  • Joined: 11-May 12

Re: Wildcard Semi-Consistent Bug using FileInfo

Posted 28 June 2013 - 06:40 AM

Lar3ry,

I didn't know about that and that is interesting, but upon further reading, from the wiki, the 8.3 SFN (short file name) truncates at the 6th character in, which in the cases I've listed would cause the "FC" file to be "DTI062~1.txt" which still does not contain "F1" so I think we are getting closer just not there yet. I'm definitely going to look into this 8.3 file name format some more though. If you or anyone else has any other thoughts, or think I've spoken incorrectly about this please let me know :)/>

Thanks!

This post has been edited by ybadragon: 28 June 2013 - 06:41 AM

Was This Post Helpful? 0
  • +
  • -

#5 ybadragon  Icon User is offline

  • D.I.C Addict
  • member icon

Reputation: 151
  • View blog
  • Posts: 968
  • Joined: 11-May 12

Re: Wildcard Semi-Consistent Bug using FileInfo

Posted 28 June 2013 - 06:49 AM

After reading some more, I've found this

Quote

Beginning with Windows 2000, if at least 4 files or folders already exist with the same initial 6 characters in their short names, the stripped LFN is instead truncated to the first 2 letters of the basename (or 1 if the basename has only 1 letter), followed by 4 hexadecimal digits derived from an undocumented hash of the filename, followed by a tilde, followed by a single digit, followed by a period ".", followed by the first 3 characters of the extension.
Example: "TextFile.Mine.txt" becomes "TE021F~1.TXT".


Which does explain the scenario I've got, however in code is "F~1" the same as "F1"?
Was This Post Helpful? 0
  • +
  • -

#6 lar3ry  Icon User is offline

  • Coding Geezer
  • member icon

Reputation: 310
  • View blog
  • Posts: 1,290
  • Joined: 12-September 12

Re: Wildcard Semi-Consistent Bug using FileInfo

Posted 28 June 2013 - 07:15 AM

View Postybadragon, on 28 June 2013 - 07:49 AM, said:

Quote

Beginning with Windows 2000, if at least 4 files or folders already exist with the same initial 6 characters in their short names, the stripped LFN is instead truncated to the first 2 letters of the basename (or 1 if the basename has only 1 letter), followed by 4 hexadecimal digits derived from an undocumented hash of the filename, followed by a tilde, followed by a single digit, followed by a period ".", followed by the first 3 characters of the extension.
Example: "TextFile.Mine.txt" becomes "TE021F~1.TXT".

Which does explain the scenario I've got, however in code is "F~1" the same as "F1"?

Possibly, perhaps even Probably! I have a feeling that "under the hood", the tilde character, as it is replacing several other characters, might be ignored in the pattern matching. If that's true, I would consider that to be, if not a bug, at least a design deficiency. Were I writing the .Net framework, I'd be tempted to add a flag to GetFiles() allowing the coder to specify no shortened filenames. I'd probably call the flag "Pathetic.Lim", and use it as a boolean. :bigsmile:/>
Was This Post Helpful? 0
  • +
  • -

#7 ybadragon  Icon User is offline

  • D.I.C Addict
  • member icon

Reputation: 151
  • View blog
  • Posts: 968
  • Joined: 11-May 12

Re: Wildcard Semi-Consistent Bug using FileInfo

Posted 28 June 2013 - 07:24 AM

That's what I was thinking too, that the tilde may just be, for lack of a better term, a pointer to the actual filename. I wish the hash that it uses wasn't "undocumented", because I want to see how it is created. Anyway thanks for helping me clarify that! :D
Was This Post Helpful? 0
  • +
  • -

Page 1 of 1