Welcome!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

SignUp Now!

Unexpected file deletion

Emilio III

Emilio III

Mar
28
0
I received an email asking for the Dell service tag of my laptop,
suggesting that I could just run \\zeus\software$\info.exe if I didn't
want to undock it and look on the bottom. I thought to copy it to my c:
drive and run it from there, so I copied the link in Eudora and pasted
it after "copy" in Take Command
([C:\]ver /r
TCC 10.00.57 Windows XP [Version 5.1.2600]
TCC Build 57 Windows XP Build 2600 Service Pack 3
Registered to Emilio Perea - 1 System License)

Unfortunately, I foolishly chose Paste+Run and this was the result:

[C:\]copy file:////zeus/software$/info.exe
TCC: (Sys) The parameter is incorrect.
"oftware$"
Deleting C:\AUTOEXEC.BAT
Deleting C:\boot.ini
Deleting C:\CONFIG.SYS
Deleting C:\dell.sdr
Deleting C:\hiberfil.sys
Deleting C:\IO.SYS
Deleting C:\MSDOS.SYS
Deleting C:\NTDETECT.COM
Deleting C:\ntldr
Deleting C:\pagefile.sys
Deleting C:\0\0K92.p10
Deleting C:\0\2005 Boys TAC Schedule1.pdf
Deleting C:\0\209.51.2
Deleting C:\0\3cinv1.c
Deleting C:\0\AccessPorts.txt
Deleting C:\0\adduser
Deleting C:\0\Admin_Logic.efx
Deleting C:\0\Aeros Easter Weekend Flyer.pdf
Deleting C:\0\allwei.txt
Deleting C:\0\AP507294-BR
Deleting C:\0\AP507301-BR
Deleting C:\0\APTEST
... etc.

I didn't realize that what would be pasted was not what I saw, but even
then I don't understand why it started to delete all my files.
 
You are not the first to experience this.. I did too as I mentioned here dated 2009-02-19, although nobody bothered to answer or react to it.

In my question I was looking for a way to encode strings to avoid things like that.

To me it seems there is a very serious bug somewhere which forces deletion of an entire drive for no apparent reason.
 
Even if this is not a bug, I wish a tcmd guru would comment on this.

I would not like to stumble over this, whatever it is.





On Mon, 2009-03-09 at 18:02 -0500, Emilio III wrote:

> ---Quote (Originally by myarmor)---
> You are not the first to experience this.. I did too as I mentioned here (http://jpsoft.com/forums/showthread.php?t=975) dated 2009-02-19, although nobody bothered to answer or react to it.
> ---End Quote---
> I scanned the thread subjects but didn't make the connection...
>
>
>
>
Click to expand...
 
Emilio III said:
I scanned the thread subjects but didn't make the connection...
Click to expand...

It was in the text itself.. A rather big part of my post.
I guess I used a more common (for me) name for what I was trying to achieve in the subject of that thread though.

At that point the drive deletion was secondary and therefore not in the subject, but now with more people experiencing the same it isn't anymore.
 
On Mon, 09 Mar 2009 18:41:37 -0500, drrob106 <> wrote:

|I would not like to stumble over this, whatever it is.

DON'T DO THIS!

I found it hard to believe, but after copying from a forum post and pasting into
TCC, I got the same result (below). It actually deleted everything on my v:\
drive (no big deal). It's so bizarre I hesitate to call it a bug. But it
certainly could be disastrous!

v:\> copy file:////zeus/software$/info.exe
TCC: (Sys) The parameter is incorrect.
"oftware$"
Deleting V:\999.bmp
Deleting V:\anagram.bat
Deleting V:\assign.btm
Deleting V:\avetemp.txt
Deleting V:\avetemp2.bat
Deleting V:\cd.btm
Deleting V:\dir.out
Deleting V:\dirhistory.txt
Deleting V:\diskpart.scr
Deleting V:\dosdtest.btm
Deleting V:\du.txt
[snip]

45 files deleted
0 files copied
--
- Vince
 
On Mon, Mar 09, 2009 at 07:44:10PM -0500, vefatica wrote:

> On Mon, 09 Mar 2009 18:41:37 -0500, drrob106 <> wrote:
>
> |I would not like to stumble over this, whatever it is.
>
> DON'T DO THIS!
>
> I found it hard to believe, but after copying from a forum post and pasting into
> TCC, I got the same result (below). It actually deleted everything on my v:\
> drive (no big deal). It's so bizarre I hesitate to call it a bug. But it
> certainly could be disastrous!
Click to expand...

I lost 608 files and 6 directories before ^C stopped it just in time
(the next directory contained several files which had changed several
times since the last backup)! No serious damage this time, but it could
have been bad news.
 
Emilio III wrote:

> I received an email asking for the Dell service tag of my laptop,
> suggesting that I could just run \\zeus\software$\info.exe if I didn't
> want to undock it and look on the bottom. I thought to copy it to my c:
> drive and run it from there, so I copied the link in Eudora and pasted
> it after "copy" in Take Command
> ([C:\]ver /r
> TCC 10.00.57 Windows XP [Version 5.1.2600]
> TCC Build 57 Windows XP Build 2600 Service Pack 3
> Registered to Emilio Perea - 1 System License)
>
> Unfortunately, I foolishly chose Paste+Run and this was the result:
>
> [C:\]copy file:////zeus/software$/info.exe
> TCC: (Sys) The parameter is incorrect.
> "oftware$"
> Deleting C:\AUTOEXEC.BAT
> Deleting C:\boot.ini
> Deleting C:\CONFIG.SYS
> Deleting C:\dell.sdr
> Deleting C:\hiberfil.sys
Click to expand...

The command line was perfectly legal, albeit interestingly malformed (in
a horrible way), and TCC executed as would be expected.

First, it found the source file name:

file:

Then a mass of mangled switches:


////zeus/software$/info.exe

And since no target was specified, it defaulted to the current directory:

c:\*

Now the fun part -- one of your switches specified you want to remove
everything in the target directory that didn't exist in the source
directory, so it started looking for files like:

file:autoexec.bat
file:boot.ini

etc., and not having much luck with them, removed the corresponding ones
in your C:\ drive. (Since you also specified a /S switch, it will
cheerfully continue in your subdirectories.)

Now, if you wanted the *correct* way to do this -- add quotes around the
"file:////...." construct so that COPY won't try to parse it as switches.

Rex Conn
JP Software
 
I think a fix should be released for this ASAP because you never know when you encounter this issue, and it is scary plain and simple..

I'm not sure, but I could imagine this happening with just about any command as it seems something is wrong with the parameter parsing itself.
I guess the bug has been present in all v10 versions.

Edit: I typed this before seeing the response from rconn
 
@rconn, when I experienced it I used the copy command with a web address.. i.e http://

I guess it would still do what you described, but it is far from expected behaviour as forward slashes etc is to be expected in a web address..

May I suggest something be done with this for known protocols (http,ftp, file etc) to prevent this from happening?
And "Invalid parameter" error THEN still performing the operation in this case is particulary bad.
 
myarmor wrote:

> I think a fix should be released for this ASAP because you never know when you encounter this issue, and it is scary plain and simple..
Click to expand...

The word "fix" is misleading, since TCC is doing exactly what you asked
it to do. IMO it's not the job of the command processor to determine
that you asked it to do something catastrophic and/or dumb! :-)
(Should TCC refuse to do a "del /s *", regardless of how many times you
told it you really wanted it done?)

The "fix" would also require removing several very popular features, so
I don't know that it would be very well received.


> I'm not sure, but I could imagine this happening with just about any command as it seems something is wrong with the parameter parsing itself.
> I guess the bug has been present in all v10 versions.
Click to expand...

It has nothing to do with the TCC parser or parameter parsing in
general. It's strictly an issue with the options you pass to a couple
of commands (which are being parsed as they should be).

It could happen with COPY or MOVE, and in a somewhat different format
with DEL. It couldn't happen with any other command, as no others have
an option to delete target files that don't match the source files.

Rex Conn
JP Software
 
myarmor wrote:

> @rconn, when I experienced it I used the copy command with a web address.. i.e http://
>
> I guess it would still do what you described, but it is far from expected behaviour as forward slashes etc is to be expected in a web address..
Click to expand...

Did you quote the web address (as is required)?

The problem with unquoted forward slashes being sometimes path
separators and sometimes option switches will need to be taken up with
Microsoft!

TCC does not support the (useless, and not supported by the necessary
Windows APIs) file:// prefix, only HTTP, HTTPS, FTP, FTPS, and TFTP.

Rex Conn
JP Software
 
On Mon, Mar 09, 2009 at 08:45:15PM -0500, rconn wrote:

> The command line was perfectly legal, albeit interestingly malformed (in
> a horrible way), and TCC executed as would be expected.
>
> First, it found the source file name:
>
> file:
>
> Then a mass of mangled switches:
>
>
> ////zeus/software$/info.exe
Click to expand...

OK, that makes sense. Unfortunately, quoting the "switches" was not
feasible since I was not expecting it to be anything other than
"\\zeus\software$\info.exe". I'll be more careful next time (and avoid
paste+run except from a plain text editor)!
 
@rconn, I guess you're right.. except on maybe one thing.. Shouldn't "Invalid parameter" stop that particular command immediately (or rather not start it at all)?
 
rconn wrote:
| The command line was perfectly legal, albeit interestingly malformed
| (in
| a horrible way), and TCC executed as would be expected.
|
| First, it found the source file name:
|
| file:

I thought that a terminating colon ":" is only accepted in directory aliases
and in pseudodevice and IP names, but causes parsing error in all other file
specifications...

| ...
| Now the fun part -- one of your switches specified you want to remove
| everything in the target directory that didn't exist in the source
| directory, so it started looking for files like:
|
| file:autoexec.bat
| file:boot.ini
|
| etc., and not having much luck with them, removed the corresponding
| ones
| in your C:\ drive.

Which switch in COPY requests it to REMOVE target files? I could not find
anything about it in help topic copy.htm" last edited 10/21/2008. I thought
that's the domain of SYNC, and COPY will never delete target files!
--
Steve
 
Could someone list the switches triggered by the OPs url?
I can only see (if it is somewhat strangely parsed) /z /s /i"nfo"

In other words copy files where description matches "nfo" in all subdirs from drive file: and overwrite destination regardless of attribute.

This is based on the help for the copy command, although I think file: would be an invalid drive to copy from normally.
 
I eventually reduced it to this. Removing any of the characters below
stops deleting files. I don't see /W documented in HELP COPY. What is
/W?

*copy fi: // /s /w


On Tue, Mar 10, 2009 at 8:05 AM, myarmor <> wrote:

> Could someone list the switches triggered by the OPs url?
> I can only see (if it is somewhat strangely parsed) /z /s /i"nfo"
>
> In other words copy files where description matches "nfo" in all subdirs from drive file: and overwrite destination regardless of attribute.
>
> This is based on the help for the copy command, although I think file: would be an invalid drive to copy from normally.
>
>
>
>
>
Click to expand...



--
Jim Cook
2009 Saturdays: 4/4, 6/6, 8/8, 10/10, 12/12 and 5/9, 9/5, 7/11, 11/7.
Next year they're Sunday.
 
Steve Fábián wrote:

> rconn wrote:
> | The command line was perfectly legal, albeit interestingly malformed
> | (in
> | a horrible way), and TCC executed as would be expected.
> |
> | First, it found the source file name:
> |
> | file:
>
> I thought that a terminating colon ":" is only accepted in directory aliases
> and in pseudodevice and IP names, but causes parsing error in all other file
> specifications...
Click to expand...

"file:" *is* an ip name. And the parser doesn't know that it's an
invalid name until it's in the middle of the COPY command. (The
arguments are parsed and expanded as they are encountered during COPY
execution.)

Rex Conn
JP Software
 
On Tue, 10 Mar 2009 15:50:34 -0500, rconn <> wrote:

|/W is an undocumented switch used internally by TCC.

Is it what caused the deletions? It seems dangerous to use an ordinary letter
for a switch intended for internal use, especialy if the consequences of using
it by mistake could be disastrous. Couldn't you use something more obscure like
a byte order mark?
--
- Vince
 
vefatica said:
On Tue, 10 Mar 2009 15:50:34 -0500, rconn <> wrote:

|/W is an undocumented switch used internally by TCC.

Is it what caused the deletions? It seems dangerous to use an ordinary letter
for a switch intended for internal use, especialy if the consequences of using
it by mistake could be disastrous. Couldn't you use something more obscure like a byte order mark?
Click to expand...

I think it's there because COPY shares parsing routines with SYNC. It'd be nice if /W following COPY tripped an error, though.
 
On Tue, 10 Mar 2009 18:13:01 -0500, Charles Dye <> wrote:

|---Quote (Originally by vefatica)---
|On Tue, 10 Mar 2009 15:50:34 -0500, rconn <> wrote:
|
||/W is an undocumented switch used internally by TCC.
|
|Is it what caused the deletions? It seems dangerous to use an ordinary letter
|for a switch intended for internal use, especialy if the consequences of using
|it by mistake could be disastrous. Couldn't you use something more obscure like a byte order mark?
|---End Quote---
|I think it's there because COPY shares parsing routines with SYNC. It'd be nice if /W following COPY tripped an error, though.

I figured that. I do similar things in my plugins but when I do, I use really
bizarre parameters that users are not likely to stumble upon.
--
- Vince
 
In other words, it would trigger on any webaddress starting with http://www too?

I noticed that almost every url given as an example url in the help file is shown without quotes.

Somehow the copy command used with a url seems more dangerous than the del command because you expect del to delete something when ran but you don't expect copy to do the same.
At least not under normal circumstances such as a webaddress, as copy apparently supports it and thereby should somehow expect it with or without quotes.
 
rconn:
| /W is an undocumented switch used internally by TCC.

vefatica:
| Is it what caused the deletions? It seems dangerous to use an
| ordinary letter for a switch intended for internal use,
| especialy if the consequences of using it by mistake could be
| disastrous. Couldn't you use something more obscure like a byte
| order mark?

Charles Dye:
| I think it's there because COPY shares parsing routines with SYNC.
| It'd be nice if /W following COPY tripped an error, though.

vefatica:
| I figured that. I do similar things in my plugins but when I do, I
| use really bizarre parameters that users are not likely to stumble
| upon.

... such as the method used for GOSUB variables.

Yes, I agree, there should not be a single undocumented thing that a user
can enter by the slip of a finger which can cause irreversible change, such
as the file deletion by a command documented to do nothing but create files.
Documented is OK - user's already know that careless use of DEL can kill
their whole system.
--
Steve
 
Steve Fábián said:
Yes, I agree, there should not be a single undocumented thing that a user
can enter by the slip of a finger which can cause irreversible change, such
as the file deletion by a command documented to do nothing but create files.
Documented is OK - user's already know that careless use of DEL can kill
their whole system.
Click to expand...

I don't think the copy command should be deleting files, whether documented or not.
 
I agree. Copy should never delete anything.

I wrote code for 30 years as a living and would never allow a user's incorrect
or ambiguous input to cause unexpected consequences.

Dennis
 
I agree, too.

In my opinion, a COPY command should never delete anything, except a file it is replacing at the destination. Any qualifier ("switch") for the command should be documented at least to the extent that says it's for internal use, should not be specified by the user, and may cause unintended and unforeseen effects. It would be better if such a switch were simply rejected with a status code if entered interactively.
 
This issue seems to be corrected in 10.0.58.
At least the OPs example doesn't trigger it anymore (I guess/hope the same is the case with http, ftp and ftps).

For some reason I had to copy perl510.dll into my VMs system32 folder before TCMD would run at all (fresh first time install of v10). even with no previous config associated with jpsoft or tcmd in the registry or as a file.
 
You must log in or register to reply here.
Back
Top
[FOX] Ultimate Translator
Translate