Bug in VFP 7 SP1 to watch out for!!!!

Am I the only one who didn't know this?

I have some test code that creates text files that begin with the letters CO
and have no extension. So these files would be "CO*."

When I do a directory for these files using

DIR CO*.

I get a list of the text files that I created.

When I then type

ERASE CO*.

it does the same as if I had typed ERASE CO*.*

I don't know if VFP 9 is similarly affected but this could be potentially
very bad. Of all commands in the world that should know the difference
between xxx*. and xxx*.* erase would be the most important.

Also, VFP's erase does not put things in the recycle bin. In my case,
everything important was backed up so no real trouble was caused.

This is, in my opinion, a very bad bug.

Jeff

Jeff
Wed Oct 25 11:58:39 CDT 2006

I just did the experiment with VFP 9 with the same result.

I went to a folder with one file

2006102500001.PDF

I did

DIR 2006*.

in the command window and it showed no files

then I typed

ERASE 2006*.

and my PDF files went bye bye.

Very bad behavior....

Jeff
"Jeff Grippe" <jgrippe@hilldun.com> wrote in message
news:12jv5ij67ktuafc@news.supernews.com...
> Am I the only one who didn't know this?
>
> I have some test code that creates text files that begin with the letters
> CO and have no extension. So these files would be "CO*."
>
> When I do a directory for these files using
>
> DIR CO*.
>
> I get a list of the text files that I created.
>
> When I then type
>
> ERASE CO*.
>
> it does the same as if I had typed ERASE CO*.*
>
> I don't know if VFP 9 is similarly affected but this could be potentially
> very bad. Of all commands in the world that should know the difference
> between xxx*. and xxx*.* erase would be the most important.
>
> Also, VFP's erase does not put things in the recycle bin. In my case,
> everything important was backed up so no real trouble was caused.
>
> This is, in my opinion, a very bad bug.
>
> Jeff
>

Lew
Wed Oct 25 13:39:49 CDT 2006

AFAIK, all versions of foxpro share this behavior which is also shared by
xBase in general. Maybe the language originators felt that this behavior
required less knowledge of the underlying operating system and would be
appreciated by desktop users. The thing to keep in mind is that all xBase
file functions obey the rules of xBase first and the os second. This
includes the way they resolve paths and wildcards. You could develop a bunch
of file routines based on win32.api or just stay mindful of the limitations.
In any event, this isn't a bug, imo.
-Lew
"Jeff Grippe" <jgrippe@hilldun.com> wrote in message
news:12jv5ij67ktuafc@news.supernews.com...
> Am I the only one who didn't know this?
>
> I have some test code that creates text files that begin with the letters
> CO and have no extension. So these files would be "CO*."
>
> When I do a directory for these files using
>
> DIR CO*.
>
> I get a list of the text files that I created.
>
> When I then type
>
> ERASE CO*.
>
> it does the same as if I had typed ERASE CO*.*
>
> I don't know if VFP 9 is similarly affected but this could be potentially
> very bad. Of all commands in the world that should know the difference
> between xxx*. and xxx*.* erase would be the most important.
>
> Also, VFP's erase does not put things in the recycle bin. In my case,
> everything important was backed up so no real trouble was caused.
>
> This is, in my opinion, a very bad bug.
>
> Jeff
>

Jeff
Wed Oct 25 13:53:39 CDT 2006

Well you could make that arguement but then I would say that DIR and ERASE
should behave the same way given the same arguements.

If "DIR CO*." had returned a list of files that matched "DIR CO*.*" then I
never would have typed "ERASE DIR CO*."

As far as I know the rule is that "DIR CO*" (without the .) will return a
list of database files whose name begins with CO. Once you put the . for the
extension the DIR is supposed to return something like an OS Directory.

In any case, DIR and ERASE should work the same.

The following is from the 7.0 help file on DIR. There is nothing in the help
for ERASE that says it should work any differently.

Include FileSkeleton to display information about file types other than
tables. FileSkeleton is a file specification skeleton that supports
wildcards. For example, to list all program files in the current directory,
issue the following command:

DIR *.PRGIn Visual FoxPro, you can issue the following command to list all
files without extensions:

DIR *."Lew Schwartz" <lschwartz@sionline.com> wrote in message
news:OIDEhRG%23GHA.5092@TK2MSFTNGP04.phx.gbl...
> AFAIK, all versions of foxpro share this behavior which is also shared by
> xBase in general. Maybe the language originators felt that this behavior
> required less knowledge of the underlying operating system and would be
> appreciated by desktop users. The thing to keep in mind is that all xBase
> file functions obey the rules of xBase first and the os second. This
> includes the way they resolve paths and wildcards. You could develop a
> bunch of file routines based on win32.api or just stay mindful of the
> limitations. In any event, this isn't a bug, imo.
> -Lew
> "Jeff Grippe" <jgrippe@hilldun.com> wrote in message
> news:12jv5ij67ktuafc@news.supernews.com...
>> Am I the only one who didn't know this?
>>
>> I have some test code that creates text files that begin with the letters
>> CO and have no extension. So these files would be "CO*."
>>
>> When I do a directory for these files using
>>
>> DIR CO*.
>>
>> I get a list of the text files that I created.
>>
>> When I then type
>>
>> ERASE CO*.
>>
>> it does the same as if I had typed ERASE CO*.*
>>
>> I don't know if VFP 9 is similarly affected but this could be potentially
>> very bad. Of all commands in the world that should know the difference
>> between xxx*. and xxx*.* erase would be the most important.
>>
>> Also, VFP's erase does not put things in the recycle bin. In my case,
>> everything important was backed up so no real trouble was caused.
>>
>> This is, in my opinion, a very bad bug.
>>
>> Jeff
>>
>
>

Jeff
Wed Oct 25 14:02:33 CDT 2006

"Lew Schwartz" <lschwartz@sionline.com> wrote in message
news:OIDEhRG%23GHA.5092@TK2MSFTNGP04.phx.gbl...
> AFAIK, all versions of foxpro share this behavior which is also shared by
> xBase in general. Maybe the language originators felt that this behavior
> required less knowledge of the underlying operating system and would be
> appreciated by desktop users. The thing to keep in mind is that all xBase
> file functions obey the rules of xBase first and the os second. This
> includes the way they resolve paths and wildcards. You could develop a
> bunch of file routines based on win32.api or just stay mindful of the
> limitations. In any event, this isn't a bug, imo.
> -Lew


Just for yucks I tried this in FPD 2.6 DOS.

I created a folder with one file name 2005.PDF. I used SET DEFAULT to make
it my current directory.

I issued the command DIR 2005*. and got no files back

I issued the command ERASE 2005*. and got back a message that says "File
does not exist."

Finally I issued the command ERASE 2005.PDF and got back a message that says
"File has been deleted."

It would appear that in FPD 2.6 DOS, the behavior is as I would expect it to
be.

So I would call it a bug and I still insist it is quite a dangerous one at
that.

Jeff

Bernhard
Wed Oct 25 14:20:28 CDT 2006

Hi Jeff,

> Also, VFP's erase does not put things in the recycle bin. In my case,
> everything important was backed up so no real trouble was caused.
At least in VFP 9, ERASE has an additional clause: RECYCLE, this puts the
deleted files in the recycle bin.

Regards
Bernhard Sander