ERASE crashes TCC

[krischik]

This might be related to the SYNC problem I reported before. The following command crashed TCC:

ERASE /E /S /X /Y /Z /K FX-602P-Droid\gen.DELETE

The directory itself does not contain a lot:

>dir /SFA FX-602P-Droid\gen.DELETE
C:\Work\uiq3\JavaME\FX-602P-Droid\gen.DELETE\.
C:\Work\uiq3\JavaME\FX-602P-Droid\gen.DELETE\..
C:\Work\uiq3\JavaME\FX-602P-Droid\gen.DELETE\net
C:\Work\uiq3\JavaME\FX-602P-Droid\gen.DELETE\net\.
C:\Work\uiq3\JavaME\FX-602P-Droid\gen.DELETE\net\..

TCC also crashes when I try a simple RMDIR. And I just noticed: The crash is after one file/directory has been deleted. Having done a couple of test runs all data is now gone.

And last not least (with another directory which behaved badly):

>\cygwin\bin\rm --recursive --verbose FX-603P-Droid\gen.DELETE
cygwin warning:
  MS-DOS style path detected: /cygdrive/c/Work/uiq3/JavaME/FX-603P-Droid\gen.DELETE
  Preferred POSIX equivalent is: /cygdrive/c/Work/uiq3/JavaME/FX-603P-Droid/gen.DELETE
  CYGWIN environment variable option "nodosfilewarning" turns off this warning.
  Consult the user's guide for more details about POSIX paths:
    http://cygwin.com/cygwin-ug-net/using.html#using-pathnames
removed directory: `FX-603P-Droid\\gen.DELETE/net/sourceforge/uiq3'
removed directory: `FX-603P-Droid\\gen.DELETE/net/sourceforge'
removed directory: `FX-603P-Droid\\gen.DELETE/net'
removed directory: `FX-603P-Droid\\gen.DELETE

 

[rconn]

> This might be related to the SYNC problem I reported before.

Try adding a /NNT option to the command line and see if it still crashes.

Did you look for the TCMD.GPF file?

 

[krischik]

Try adding a /NNT option to the command line and see if it still crashes.

Copies fine. Having had a look in the help file and since there are no descriptions in the source I might delete my JPSTREE.IDX and see what happens.

Indeed - the copy is now ok without /NNT as well.

Did you look for the TCMD.GPF file?

I did not know the file exist but here you are:

Module=C:\opt\JPSoft\TCCLE12\TakeCmd.dll
Address=100091E3
Exception=C0000005
EAX=00000000  EBX=76ED4EF8  ECX=00000000  EDX=00000000
ESI=76ED22FB  EDI=76B87C12  EBP=0168ACD4  ESP=01686888
CS=00000023  DS=0000002B  ES=0000002B  SS=0000002B
Flags=00010246

Stack:
1 : TakeCmd.dll 0001:000081e3
2 : TakeCmd.dll 0001:000080d0
3 : TakeCmd.dll 0001:00056b2a
4 : TakeCmd.dll 0001:00056456
5 : TakeCmd.dll 0001:0005613b

 

[rconn]

Copies fine. Having had a look in the help file and since there are no descriptions in the source I might delete my JPSTREE.IDX and see what happens.

Indeed - the copy is now ok without /NNT as well.

I wish you hadn't deleted JPSTREE.IDX; it would have been useful to me to see it and see (1) if it was corrupted (most likely) and (2) exactly how that crashed TCC.

Let me know if it happens again after recreating JPSTREE.IDX.

 

[krischik]

I wish you hadn't deleted JPSTREE.IDX; it would have been useful to me to see it and see (1) if it was corrupted (most likely) and (2) exactly how that crashed TCC.

It is your lucky day: I am the customer who uses “Delete to Recycle Bin” ;). I send a download link as PM.

 

[rconn]

It is your lucky day: I am the customer who uses “Delete to Recycle Bin” ;). I send a download link as PM.

I didn't receive anything -- where did you send it? (The best place is [email protected].)

 

[krischik]

where did you send it?

http://jpsoft.com/contact.htm

But it went to your email as well now.

 

[rconn]

> ---Quote (Originally by rconn)---
> where did you send it?
> ---End Quote---
> http://jpsoft.com/contact.htm
>
> But it went to your email as well now.

That file *is* corrupted (it is a horrible combination of Unicode and ASCII
text; I've never seen anything like it).

Rex Conn
JP Software

 

[krischik]

That file *is* corrupted (it is a horrible combination of Unicode and ASCII text; I've never seen anything like it).

I had some trouble with the code pages and I tried various combinations to find out what suits me best.

But this should not corrupt the file. In these day an age it would be best to always store Unicode - because that is what the file system uses.

 

[rconn]

I had some trouble with the code pages and I tried various combinations to find out what suits me best.

But this should not corrupt the file. In these day an age it would be best to always store Unicode - because that is what the file system uses.

Any chance you ran an older version of 4NT / Take Command (that doesn't support Unicode) that might have updated (and corrupted) JPSTREE.IDX?

 

[krischik]

Any chance you ran an older version of 4NT / Take Command (that doesn't support Unicode) that might have updated (and corrupted) JPSTREE.IDX?

I have both TakeCommand and TCC/LE installed.

So yes: why I was updating those copies there as a small time frame where a mix was on the machine.

Martin