On Wed, 20 May 2009, Szak�ts Viktor wrote:
> To be more precise it isn't a bug in DIRECTORY() but it's
> rather some strange property of Windows FileFind API,
> we should probably work it around in core code, to avoid
> doing such ugly hacks on app level.
> Currently on Windows DIRECTORY( "*.ext" ) will return
> "*.ext*". This only happens when the extension is three
> chars long. I just can guess this is another weird attempt
> by MS to solve some compatibility issues.
> Anyone knowing more about this phenomenon?
I only guess so it's possible that I'm wrong but AFAIR MS-Win write each
file with two name: full_name and short_name which is in 8.3 format.
Each file with extension longer then 3 bytes after conversion to 8.3
format has as extension first 3 bytes from original extension.
FindFirstFile()/FindNextFile() respects both short and long names
so if you use *.prg pattern then you also see all files which has
prg extension after conversion to 8.3 format.
If I'm right then using longer extensions in MS-Windows is very bad idea
because for many programs only the 1-st three characters will be significant
due to 8.3 aliases created for such names in directories. We should remember
about it in the future.
Now we have the question: Should we accept aliases or not?
In summary these are valid names which match given wild pattern like *.prg.
I guess that in Clipper:
aeval( directory( "*.prg" ), {|x,i|qout(i,x[1],x[2],x[3],x[4],x[5])} )
also shows the same files though using short 8.3 names.
We can add additional code which will ignore 8.3 aliases and verifying the
results using long file names but the above code will show different list
of files then in Clipper. I'm not MS-Windows users so I should not decide
here. Personally I'd prefer using real names only and ignore aliases but
I do not know how it may interact with real life code in Windows.
If you decide to add such file name verification then it can be quite
easy implemented and I can do that.
best regards,
Przemek
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
