>>

>>STRTOFILE("prova","nomefile.extension")
>>=FILETOSTR("nomefile.extension") && EXISTS
>>DELETE FILE  "x.ext"
>>=FILETOSTR("nomefile.extension") && EXISTS
>>DELETE FILE  "*.ex"
>>=FILETOSTR("nomefile.extension") && EXISTS
>>DELETE FILE  "*.exte"
>>=FILETOSTR("nomefile.extension") && EXISTS
>>DELETE FILE  "*.ext" && 3 extension chars
>>=FILETOSTR("nomefile.extension") && DELETED !!!!
>>

>
>That's probably happening because of short filename matching the pattern (and I believe the unintended short filename isn't a VFP bug, but a "as designed" situation with the OS). If I'm not mistaken, in the "mangling" process into short name, extensions longer than 3 characters are truncated to 3 characters and the stem portion is "mangled" for the short filename. In the last DELETE FILE you are wildcarding -- so it *will* match the "mangled" short name (and thus getting additional files deleted unintentionally). You can verify this at the command line (just use DIR /X to view short filenames) -- and I believe that if you repeated same sort of steps in at the command line, you're likely to get the same sort of results. If you're using NTFS, I believe you can disable the short filename feature.
>
>Speaking of short filename woes... I ran into similar sort of problem many years ago with an older version of Novell Netware -- where the mangling rule was slightly different from how post-95 Windows handles it. Long filenames are "mangled" by first truncating to 8.3 format (win95 and later will truncate extension and mangle stem portion). Say for example you've got "testfile01.document" -- Netware mangled this to "testfile.doc" (Win95 would mangle to "testfi~1.doc"). Let's say you now try to create a "testfile15.document" -- this gets "mangled" into "testfil1.doc" (windows would mangle to "testefi~2.doc" to avoid collision with previous one). Now guess what happens when you try to create the file "testfile.doc" ? The "testfile01.document" gets deleted! This was because short filenames have precedence. Even if it didn't you'd end up with a confusing situation because now "testfile.doc" needs to be "mangled" to avoid collision with the "mangled" version of "testfile01.doc" -- so you're likely to have "testfile.doc" needing to be "mangled" as "testfil3.doc". Of course, this results in an even more confusing situation -- attempts to open "testfile.doc" would open "testfile01.document" instead because short filenames had precedence, and to open the intended "testfile.doc" you'd need to open "testfil3.doc" (which unfortunately won't show in the GUI!). Of course, the *really* bad part was when you tried to copy "testfile.doc" from some other location, the "testfile1.document" would be deleted in the process! There was a patch you had to install to change the "mangling" for short filename so that you don't have this problem (it changed the "mangling" rules to match those used in Win95) -- of course the "fix" didn't change existing short filenames, so I was forced to copy all the files off, then back onto the Novell volume so that the short filenames were re-generated.

I think it is as you say.
I have a shared folder on the defect,
on my pc, where NtfsDisable8dot3NameCreation = 1
the defect does not occur!
This is a bad windows's design
because it makes the software inaccurate.