Timo Salmi wrote:
> On 31.10.2011 04:02 Tom Del Rosso wrote:
> > I just got bitten by a bug where 'dir *84*.*' for example matched
> > some unwanted files by their short names, but I only want to match
> > based on the long name which doesn't contain 84 in the example case.
>
> Tom, it is difficult to address the problem, if one can't test it
> hands-on.
> Please don't get this wrong. As usual, I am probably being dense, but
> your problem documentation minimalistic and thus the situation remains
> vague. Therefore this leads to speculations. Give some example lists
> of file names (with their sfn and lfn renditions) which [a] match
> correctly [b] match incorrectly in your method.
Since I worked around it for the immediate problem, I am just looking for a
general solution.
But if it helps, suppose you are searching for 84 and you get a file with 86
just because it has 84 in the SFN. Several matches like that came up for
one search.
SFN: EN8464~1.ZIP
LFN: Eng [s02 1986].zip
Obviously I could fix it in this case by adding more characters to the
filespec, so this specific case is not what I'm asking about. I just wanted
to know if there is a general way to match filespecs to only the LFN in the
future.
At first I was very surprised to see the unwanted matches. It's not
something you expect to happen. It could happen by surprise in any other
situation where you use wildcards, possibly causing modification to the
wrong files. It's not likely we would always be careful to use extra
characters, as I was able to use "]" in this case, so to avoid an accident
it would be good if there was a way to ignore the SFN.
Turning off SFN support might even be a good idea now that we have VM's for
DOS programs, and can't even use them without a VM any more.
> P.S. have you tried through the output of ATTRIB
How can that help? It gives text to search but so does dir.