Best way to fix FileFindFirstFile?

[Jon]

This is a bug report that surprised me.

http://www.autoitscript.com/trac/autoit/ticket/2453

I had no idea that the Windows FindFirstFile/NextFile functions also searched the short filename. I can add a second stage search to ensure that only the long filenames are queried but that may very well break behaviour that people were relying on.

I'm thinking that a possible fix would be an optional 2nd parameter for both FileFindFirstFile and FileFindNextFile that indicates only the long file name should be queried. 

Any better ideas?

[Jon]

Would there ever even be a case of someone wanting to match based on short file name but not long. Hmm, maybe an optional param is overkill for an edge case.

[Ascend4nt]

Out of curiousity I went ahead and did some tests on my own using a few different methods to try to avoid matching shortnames with a wildcard spec:

• NtQueryDirectoryFile:  I used the FileDirectoryInformation class to purposefully not collect information on short filenames.
  Result: still matched the wildcard spec against shortnames.
• FindFirstFileEx (vs. FindFirstFile): I used this with fInfoLevelId (FINDEX_INFO_LEVELS enum) set to FindExInfoBasic, to skip shortnames.  Per MSDN it "does not query the short file name," which I had mistakenly assumed to mean that it would not query them as part of the search routine. (Note this option is only recognized on Win7/2008R2+)
  Result: Still matched the wildcard spec against the shortnames, even if not actually collecting them. I would posit that this is because it calls the lower level NtQueryDirectoryFile to do the searching.

So it seems that in order to skip the short filename matches problem, there is no Windows API method that works.. it has to be done using internal checks.  You can't even use PathMatchSpec, as that states it works on a maximum of MAX_PATH characters. This would require you to write your own wildcard string match function (or see "Wildcard string compare (globbing)"), or do a conversion to regular expressions and use the PCRE engine.

To me, this is way too much extra effort (and code) to workaround a Windows API failure.  Better to just document it and let people know about it.

While on the subject, it would probably be good to note (and to document) that FileGetShortName() and FileGetLongName() will fail on Windows systems where short filenames are disabled - which is more common in corporate environments where keeping short filenames impacts performance. (See 'Windows Server 2012 File Server Tip: Disable 8.3 Naming (and strip those short names too)' and  'How to Disable the 8.3 Name Creation on NTFS Partitions')

P.S. As an aside, on Win7/2008R2+, there's supposed to be performance gains in searching using FindFirstFileEx when dwAdditionalFlags is set to FIND_FIRST_EX_LARGE_FETCH, and fInfoLevelId set to FindExInfoBasic

[jchd]

MS handling of filenames is terrible. Note that you can't even characterize a short name by a tilde, since the tilde is a valid character in filenames.

[Richard Robertson]

Short names aren't even useful anymore. Why are they a feature?

I'd say it'd be better to just document it since all other Windows APIs do the same thing.

[BrewManNH]

Short names have a use if you want to be lazy and not have to worry about quoting a file path and name to avoid spaces.

[Richard Robertson]

Short names have a use if you want to be lazy and not have to worry about quoting a file path and name to avoid spaces.

But that only works if you know for sure what the short name will become and if you're writing a program, you should never expect the end user to use short names.

[BrewManNH]

That's where filegetshortname comes in, you don't need to know what it is, you just need to have something to give to that function.

[Richard Robertson]

So you're wasting extra time getting the short name when you could just put quotes around it?

[KaFu]

Shortnames are very useful when you work with programs which do not accept unicode input, e.g. like I do in AMT with MPlayer.