CINXXXX.JPS?

[vefatica]

When I use a construction like this

do x in @clip: (...)

I get CINXXXX.JPS files in %TEMP which are not deleted. Should they be deleted?

 

[rconn]

No.

 

[AnrDaemon]

Why?

 

[rconn]

Because there's no such device as "clip:". TCC fakes it with temporary files, but the creation of the clipboard temporary file and the point at which it *might* be deleted (wouldn't work in any case in pipes) are far apart (and different in every internal command that supports clip:) and there's no practical way to communicate that the temp file might be deletable now.

If it really bothers you, you should stop posting messages and close your browser, which produces far more files in your temp directory (and never deletes them).

 

[djspits]

You did notice that the last question came from somebody else than the previous one, did you Rex?

I think you could have picked up on the reasonable intent of the OP to ask about "cleaning up behind yourself".
If you had, you could have

1) admitted that TC was intentionally developed not to clean up temporary files and leave that to the user
2) suggest a couple of solutions the user could easily implement themselves, like
- pointing TMP to a scratch directory at the beginning of the script and removing it with one RD /S at the end
- adding a couple of lines at the end of the script to do specific house cleaning.
- DEFERring the deletion at the point of creation.
- developing an auto-delete temporary file
- scheduling regular cleanups

... which we could develop together and publish somewhere for everyone to use and enjoy.

... which would have been instructive and perhaps inspiring and would have been an answer on a much more appropriate level than pipes and communication of internal commands.

 

[vefatica]

Because there's no such device as "clip:". TCC fakes it with temporary files, but the creation of the clipboard temporary file and the point at which it *might* be deleted (wouldn't work in any case in pipes) are far apart (and different in every internal command that supports clip:) and there's no practical way to communicate that the temp file might be deletable now.

In the particular case of "DO var in @clip: (...)" can't the temp file be deleted at the same time that it's closed, as happens in the case of "DO var in /P command (...)"? As I see it (maybe oversimplifying) in both cases the file only exists for the sake of the DO command

 

[Charles Dye]

One approach would be to write your own replacement for GetTempFileName() and include TCC's PID in temp filenames, e.g.
JPS-CIN-xxxx-yyyyyyyy.TMP
where xxxx is your PID and yyyyyyyy is random (or incrementing, or whatever). Alternatively, create your own temp subdirectory within %TEMP%, again using TCC's PID as part of the name, and put all of your temp files there.

Either way, cleaning up your own leftovers at exit — without touching anybody else's — becomes a simple wildcard delete.

 

[rconn]

In the particular case of "DO var in @clip: (...)" can't the temp file be deleted at the same time that it's closed, as happens in the case of "DO var in /P command (...)"? As I see it (maybe oversimplifying) in both cases the file only exists for the sake of the DO command

DO doesn't know it's a temp file; all it knows is that it's reading from STDIN. The parser redirected everything before DO saw the command line.

I could probably do what you want; it just requires rewriting the parser. Probably a 2x- 3x increase in size and a corresponding decrease in performance. And so, so many new bugs ...

 

[vefatica]

DO doesn't know it's a temp file; all it knows is that it's reading from STDIN. The parser redirected everything before DO saw the command line.

I could probably do what you want; it just requires rewriting the parser. Probably a 2x- 3x increase in size and a corresponding decrease in performance. And so, so many new bugs ...

Well I didn't know how it works (still don't really). It's no big deal. I've been a bit obsessed with %TEMP lately because DevStudio Community has a "BackgroundDownload" task which runs ~20 times a day (I think it's misconfigured) and really leaves a mess in %TEMP.

 

[AnrDaemon]

If it really bothers you, you should stop posting messages and close your browser, which produces far more files in your temp directory (and never deletes them).

It does not "bother" me, if that was a reply in my address. I was honestly interested in the implementation details.

 

[Charles Dye]

I've been a bit obsessed with %TEMP lately because DevStudio Community has a "BackgroundDownload" task which runs ~20 times a day (I think it's misconfigured) and really leaves a mess in %TEMP.

Write a batch file to delete everything over, say, five days old in %TEMP. Then either use Task Scheduler to run it once a day, or local group policies to run it at login.

 

[vefatica]

Write a batch file to delete everything over, say, five days old in %TEMP. Then either use Task Scheduler to run it once a day, or local group policies to run it at login.

What I'd like to do with a batch file is what I do manually and I don't think it's possible.

I open explorer in %TEMP, press Ctrl-A (select all), press Shift-Delete (delete permanently) and answer "Skip it" for each item (usually 4 of them) that gives any sort of a prompt. That process turns this:

v:\> d t:\
2019-10-03  13:58         <DIR>    2nkiplrq.itg
2019-10-03  13:19         <DIR>    g0k53vbe.t2n
2019-10-03  12:44         <DIR>    Offline Address Books
2019-10-03  21:33         <DIR>    Outlook Logging
2019-07-02  11:58         <DIR>    System Volume Information
2019-10-03  13:19         <DIR>    VSRemoteControl
2019-10-03  13:58         <DIR>    wdszp4so
2019-10-04  09:23          12,308  AdobeARM.log
2019-10-04  06:46             470  aria-debug-2544.log
2019-10-03  13:19           2,909  dd_BackgroundDownload_20191003131952.log
2019-10-03  13:19               0  dd_BackgroundDownload_20191003131952_result_Cancel.log
2019-10-03  13:58         386,627  dd_BackgroundDownload_20191003135812.log
2019-10-03  13:58         381,455  dd_BackgroundDownload_20191003135812_00_setup.log
2019-10-03  13:58               0  dd_BackgroundDownload_20191003135812_00_setup_errors.log
2019-10-03  13:58               0  dd_BackgroundDownload_20191003135812_result_Success.log
2019-10-02  11:41       4,194,332  ExchangePerflog_8484fa31d2e07ce7cfcccd43.dat
2019-07-04  00:35               0  FXSAPIDebugLogFile.txt
2019-10-02  11:41               0  mat-debug-6528.log
2019-10-03  15:29           3,087  Olktmp.png
2019-10-03  16:23           3,087  Olktmp00.png
2019-10-03  15:25          20,561  wct99C6.tmp
2019-10-03  01:55          20,527  wct8942.tmp

into this:

v:\> d t:\
2019-07-02  11:58         <DIR>    System Volume Information
2019-10-02  11:41       4,194,332  ExchangePerflog_8484fa31d2e07ce7cfcccd43.dat
2019-07-04  00:35               0  FXSAPIDebugLogFile.txt
2019-10-02  11:41               0  mat-debug-6528.log

 

[Charles Dye]

What I'd like to do with a batch file is what I do manually and I don't think it's possible.

Hmmm. What's needed is some sort of a scriptable file-management tool. Somebody should write something like that....

Seriously, though. How does that differ from DEL /S /E /X /Y /Z * ?

 

[vefatica]

Seriously, though. How does that differ from DEL /S /E /X /Y /Z * ?

Maybe it doesn't. I was always a little afraid to automate it is such a drastic manner. I'll try it when %TEMP gets messy again.

To follow up on what Juppycmd said ... I have come to think that two guidelines are simple:

For apps: If you put something in %TEMP and don't want it deleted, keep it locked.

For users: It's safe to delete anything in %TEMP that you **can** delete.

When it comes to leaving stuff in %TEMP (and forcing the user to clean it up) guidelines are needed.

BTW, I tried Windows 10's "Disk Cleanup" utility specifying only "temporary files" when %TEMP was as in my previous post. Nothing there was deleted.

 

[Charles Dye]

Just checked my own cleanup batch file, and it deletes anything over 14 days old. Two weeks seems almost ludicrously conservative; two days would probably do just as well. But 2 days or 14, it all gets deleted eventually.

 

[vefatica]

Just checked my own cleanup batch file, and it deletes anything over 14 days old. Two weeks seems almost ludicrously conservative; two days would probably do just as well. But 2 days or 14, it all gets deleted eventually.

Is there (has there ever been) any newer stuff that you're sure had some value?

 

[Charles Dye]

Is there (has there ever been) any newer stuff that you're sure had some value?

As far as I'm concerned, anything in the temp directories is ipso facto temporary. I certainly don't keep important stuff there.

 

[Charles G]

Just checked my own cleanup batch file, and it deletes anything over 14 days old. Two weeks seems almost ludicrously conservative; two days would probably do just as well. But 2 days or 14, it all gets deleted eventually.

Be interested to see your cleanup batch file .....

 

[Charles Dye]

There's really not much to it.

C:\>type c:\Bin\Bat\PurgeTempDirs.btm
@echo off
*setlocal
*unalias *

rem     This script deletes any files over two weeks old from
rem     the user's temp directory and C:\WINDOWS\TEMP.

set n=14

alias purge=`if .%1 ne . if isdir %1 pushd %1 && ( del /[dc-%n,1980-01-01] /s /e /x /y /z * %+ popd )`

purge "%temp"
purge "%systemroot\temp"

endlocal
quit
C:\>

TCC holds a handle open to the current directory, so the PUSHD prevents DEL /X from removing the temp directory itself in the unlikely event that it is completely emptied. The conditionals at the start of the alias prevent the DEL if the directory is not specified, doesn't exist, is not accessible, etc.

I launch the script with a local policy:

 

[AnrDaemon]

By default, MS Office (and other programs) create rollback files in the %TEMP%.
Deleting them may cause unnecessary mental stress.

 

[vefatica]

Hmmm. What's needed is some sort of a scriptable file-management tool. Somebody should write something like that....

Seriously, though. How does that differ from DEL /S /E /X /Y /Z * ?

Yes, that works nicely and apparently does exactly what my manual method does. I found that prefixing that command with

except (cleantmp.btm) ...

doesn't protect cleantmp.btm. But that was easy to fix ... like this.

set h=%@fileopen[t:\cleantmp.btm,rw]
DEL /S /E /X /Y /Z t:\*
echo %@fileclose[%h] > NUL

 

[Charles Dye]

Yes, that works nicely and apparently does exactly what my manual method does. I found that prefixing that command with

except (cleantmp.btm) ...

doesn't protect cleantmp.btm. But that was easy to fix ... like this.

set h=%@fileopen[t:\cleantmp.btm,rw]
DEL /S /E /X /Y /Z t:\*
echo %@fileclose[%h] > NUL

EXCEPT just sets the hidden attribute temporarily; it's kind of a crocky holdover from DOS days. Your DEL command deletes hidden files, so the EXCEPT won't matter. You can use an exclusion range instead.

As I'm deleting by file age -- based on creation timestamp -- I can also protect files by setting the creation date to some point in the distant future:

touch /dc2199-12-31 readme.txt

 

[Kachupp]

What I'd like to do with a batch file is what I do manually and I don't think it's possible.

I open explorer in %TEMP, press Ctrl-A (select all), press Shift-Delete (delete permanently) and answer "Skip it" for each item (usually 4 of them) that gives any sort of a prompt. That process turns this:

v:\> d t:\
2019-10-03  13:58         <DIR>    2nkiplrq.itg
2019-10-03  13:19         <DIR>    g0k53vbe.t2n
2019-10-03  12:44         <DIR>    Offline Address Books
2019-10-03  21:33         <DIR>    Outlook Logging
2019-07-02  11:58         <DIR>    System Volume Information
2019-10-03  13:19         <DIR>    VSRemoteControl
2019-10-03  13:58         <DIR>    wdszp4so
2019-10-04  09:23          12,308  AdobeARM.log
2019-10-04  06:46             470  aria-debug-2544.log
2019-10-03  13:19           2,909  dd_BackgroundDownload_20191003131952.log
2019-10-03  13:19               0  dd_BackgroundDownload_20191003131952_result_Cancel.log
2019-10-03  13:58         386,627  dd_BackgroundDownload_20191003135812.log
2019-10-03  13:58         381,455  dd_BackgroundDownload_20191003135812_00_setup.log
2019-10-03  13:58               0  dd_BackgroundDownload_20191003135812_00_setup_errors.log
2019-10-03  13:58               0  dd_BackgroundDownload_20191003135812_result_Success.log
2019-10-02  11:41       4,194,332  ExchangePerflog_8484fa31d2e07ce7cfcccd43.dat
2019-07-04  00:35               0  FXSAPIDebugLogFile.txt
2019-10-02  11:41               0  mat-debug-6528.log
2019-10-03  15:29           3,087  Olktmp.png
2019-10-03  16:23           3,087  Olktmp00.png
2019-10-03  15:25          20,561  wct99C6.tmp
2019-10-03  01:55          20,527  wct8942.tmp

into this:

v:\> d t:\
2019-07-02  11:58         <DIR>    System Volume Information
2019-10-02  11:41       4,194,332  ExchangePerflog_8484fa31d2e07ce7cfcccd43.dat
2019-07-04  00:35               0  FXSAPIDebugLogFile.txt
2019-10-02  11:41               0  mat-debug-6528.log

Have you found a solution to this? or is it not bothering you in 2021 ?
If interested I altered one of your scripts to clean the temp folder works great

 

[vefatica]

Have you found a solution to this? or is it not bothering you in 2021 ?
If interested I altered one of your scripts to clean the temp folder works great

No, and I stopped looking. I keep the BTM elsewhere and clean up 3 temp directories with

DEL /S /E /X /Y /Z %_cwds*

in each one. As much as can be deleted is deleted and I don't worry about what's left.

 

[Kachupp]

No, and I stopped looking. I keep the BTM elsewhere and clean up 3 temp directories with

DEL /S /E /X /Y /Z %_cwds*

in each one. As much as can be deleted is deleted and I don't worry about what's left.

fair enough