What could be slowing a "del /sxz" command?

[Phileosophos]

I work with a lot of 3rd party source code, often fetched from GitHub, and I'm finding a reliable, vast performance difference between deleting files in Windows Explorer and using TakeCommand v13.03. For example, if I pull down the C# source code for IronFoundry (https://github.com/IronFoundry/ironfoundry.git) and later use Windows Explorer to delete the folder, it takes just a few seconds.

If I use my usual "prune" alias in TakeCommand v13.03 however, which is "del /sxz" for reference, then it takes minutes to delete all the files in the folder. I can literally watch the output scroll one line at a time while it's deleting files. So I ask: what could be slowing a "del /sxz" command so much? Any ideas? Thanks in advance!

 

[TEA-Time]

Maybe try "rd /s"?

 

[Charles Dye]

You might also try SETDOS /D0 first, to see whether it's file-description processing.

 

[Charles Dye]

Incidentally, your link is a 404, albeit a cute 404.

 

[Steve Fabian]

Some things that can slow down TCC in deleting directory trees:
1/ you do not specify that JPSTREE.IDX does not need to be updated for each directory that is deleted
2/ by default TCC deletes to the recycle bin
3/ you do not specify that you do not want each item deleted to be reported

I use the aliases ERA and EXS to delete individual files and directory trees, resp.:
era*se is an alias : *del/qyz/nejt
exs is an alias : era/x/s
USE WITH CAUTION!

 

[rconn]

Most of the time is being spent looking for matching file descriptions, which can be disabled with the DEL /nn option, and updating the JPSTREE.IDX file, which can be disabled with the /nt option. If you want to use them both, you need to combine them; i.e. /nnt.

 

[samintz]

As Steve stated, you might want to try adding /Nn and/or /Nt to prevent updates to description files and/or the jpstree.idx file.
Or /K to prevent moving to RecycleBin.
Or /Q to not print out the files being deleted.

 

[Fross]

Hmm. I just tried a delete that included the /Nn and /Nt. It didn't seem to delete if they were both on the command line. It worked if one or the other was present.

The following is my "Nuke" alias and today I added the /nn and /nt to speed it up.

Example:
*del /e /s /t /x /y /z /r /nn DirToDelete
This deleted the dir

*del /e /s /t /x /y /z /r /nt DirToDelete
This deleted the dir

*del /e /s /t /x /y /z /r /nn /nt DirToDelete
This did not delete the dir and gave a "would be deleted" message.

Can anyone else reproduce this?

Thanks,

Michael

 

[samintz]

It seems like a parsing issue. But I believe when you specify both n and t you need to combine them like /Nnt. The second /N switch gets interpreted as /N /T which does the "would be deleted" behavior.

 

[Fross]

That makes some kind of crazy parser sense. I know I tried to not combine options anymore since Rex deprecated that a few versions back. I'll give it a shot. I believe that the jpsoft.idx is the main culprit for slowing down recursive deletes, but I've not run any actual timed tests.

Thanks Scott!

 

[Steve Fabian]

That makes some kind of crazy parser sense. I know I tried to not combine options anymore since Rex deprecated that a few versions back.

There is a difference between options, and suboptions. Generally you MUST combine the suboptions.

 

[rconn]

Hmm. I just tried a delete that included the /Nn and /Nt. It didn't seem to delete if they were both on the command line. It worked if one or the other was present.

You can only have one /N option on the command line. You have to combine all of its suboptions; it's a multicharacter switch.

 

[krischik]

2/ by default TCC deletes to the recycle bin

which in itself is not that much of a performance killer. But I have seen virus checkers checking files in the recycle bin. Very helpful. I use a script to delete directories:

@ECHO OFF

SETLOCAL
  DO I IN "%$"
    RENAME "%[I]" "%[I].DELETE"
    DETACH %[COMSPEC] /C ERASE /E /S /X /Y /Z /K "%[I].DELETE"
    PRIORITY %[_DETACHPID] BELOW
  ENDDO
ENDLOCAL

 

[Phileosophos]

Thanks for all the ideas, folks. I've definitely updated my "prune" alias as a result of all this discussion, but so far nothing seems to make it any faster. It doesn't seem to matter much which of those switches I throw or whether I use that batch file (thanks much, krischik). It's just much slower than using Windows Explorer, and that's not a sentence I ever thought I'd utter about anything.

 

[rconn]

If you have file descriptions and/or a jpstree.idx (fuzzy directory search) file, then the /nnt option will make a substantial difference in execution time. If you don't have them, the difference will be minimal.

If you're not deleting to the recycle bin, the remaining difference between TCC and Explorer is that TCC supports wildcards (and RE's), so it has to examine every file in every directory to see if they match. Explorer doesn't care and just deletes everything. Then there's some minor overhead with TCC checking for aliases, expanding variables, looking for command groups and compound commands, parsing the line, etc.

 

[Phileosophos]

Good to know, thanks. Is there any way in TC to nuke a directory w/o any matching? Or am I just going to have to break down and use explorer? Thanks in advance.

 

[JohnQSmith]

Here's my super-delete alias... it just "does" without any fanfare. Works quickly for me.

alias kdel=del /k /nnt /s /q /x /y /z

 

[Steve Pitts]

Is there any way in TC to nuke a directory w/o any matching?

As per the first reply to this thread, how about:

*RD /S x:\whatever

(Be very, very careful though. One typo could lose you a lot of stuff you actually didn't expect)

 

[JohnQSmith]

(Be very, very careful though. One typo could lose you a lot of stuff you actually didn't expect)

I would like to add the same disclaimer to my alias.

 

[Charles Dye]

I would like to add the same disclaimer to my alias.

You can actually do that. XenForo allows you to edit your old posts.