C:\windows\temp cleanup?

| What is in your VBScript?
|
| I'm wanting to write a similar script with PowerShell and I need ideas for
what would go into it.

http://www.jsware.net/jsware/scrfiles.php5#desk

CleanTEMP.vbs

It's probably more than is really necessary. It checks
Windows\TEMP\, my App Data TEMP, and all other
users TEMP. (All users, default user, etc.) I've only
ever seen it find files in the first two locations.

It's just a simple script using FileSystemObject to
loop through the contents and keep going on errors,
so that it doesn't get stopped by an open file. It
then reports how much was deleted. I leave it on my
Desktop and just run it every once in awhile.

| What was the timestamp on the unlocked temp file that didn't get deleted
| by the Disk Cleanup wizard?

A few hours. So you may be onto something. I'd consider
that a bug, though. If the file is not open there's no reason
for it to be something that's still to be used. That's why it's
the "Temp" folder, after all.

On 8/31/2014 8:00 PM, Mayayana wrote:
| What is in your VBScript?
| I'm wanting to write a similar script with PowerShell and I need ideas for
what would go into it.

http://www.jsware.net/jsware/scrfiles.php5#desk
CleanTEMP.vbs
It's probably more than is really necessary. It checks
Windows\TEMP\, my App Data TEMP, and all other
users TEMP. (All users, default user, etc.) I've only
ever seen it find files in the first two locations.
It's just a simple script using FileSystemObject to
loop through the contents and keep going on errors,
so that it doesn't get stopped by an open file. It
then reports how much was deleted. I leave it on my
Desktop and just run it every once in awhile.


Thanks!

Stan Brown wrote:
On Sat, 30 Aug 2014 21:04:00 -0400, Paul wrote:
And throw out the stuff where I know there
are no open file handles associated. For example,
if Powerpoint Viewer put a temp file in there
and Powerpoint Viewer was still running, I wouldn't
attempt to delete the file


Throw out everything. Windows won't let you delete an open file, and
it can figure that out faster than you can. :-)


That's true.

But I don't even waste my time on the w32time.log,
as it is always busy. I delete that one from
another OS, when it bothers me enough. I should
probably just turn that log off, as it ceased
to be of value a long time ago.

Paul

On Sun, 31 Aug 2014 21:27:24 -0300, pjp wrote:

In article ,
says...

I'm glad you had good experiences, but I have decided not to download
Unlocker. The deal-breaker for me was this:

"Recommended before download

"RegistryBooster 2013

"This award winning software starts by conducting a deep scan of your
registry, checking for file extension errors and other registry
conflicts. With RegistryBooster you will see immediate increases in
performance and decreases in systemt conflicts."

The "systemt" typo doesn't bother me, but someone who makes that kind
of promise either doesn't know what he's talking about or is not to
be trusted.

Having some program's installer offer some other package also is nothing
new. Simply decline any extra offers during install. Unlocker itself is
quite small 117Kb for it's install folder.

Offering a recommendation is not the problem. Claiming that yet
another Registry cleaner will give "immediate increases in
performance and decreases in system conflicts" is snake oil. The
person who wrote that is either lying or ignorant, and either way I
won't let his software onto my computer.

--
Stan Brown, Oak Road Systems, Tompkins County, New York, USA
http://OakRoadSystems.com
Shikata ga nai...

Stan Brown wrote:

On Sun, 31 Aug 2014 21:27:24 -0300, pjp wrote:

In article ,
says...

I'm glad you had good experiences, but I have decided not to download
Unlocker. The deal-breaker for me was this:

"Recommended before download

"RegistryBooster 2013

"This award winning software starts by conducting a deep scan of your
registry, checking for file extension errors and other registry
conflicts. With RegistryBooster you will see immediate increases in
performance and decreases in systemt conflicts."

The "systemt" typo doesn't bother me, but someone who makes that kind
of promise either doesn't know what he's talking about or is not to
be trusted.

Having some program's installer offer some other package also is nothing
new. Simply decline any extra offers during install. Unlocker itself is
quite small 117Kb for it's install folder.

Offering a recommendation is not the problem. Claiming that yet
another Registry cleaner will give "immediate increases in
performance and decreases in system conflicts" is snake oil. The
person who wrote that is either lying or ignorant, and either way I
won't let his software onto my computer.

The millisecond decrease in load time for a larger registry will never
be noticed by the user. That had some small significance a couple
decades ago with much slower hard disks, I/O subsystems on the mobo, and
much slower CPUs (but had about 1-3 seconds difference in boot time for
Windows back then).

The registry is loaded into memory and that is where every app gets the
registry entries. RAM means random access so it doesn't take any longer
to read a part of the registry from memory just because there are
orphaned entries (which never get access because, well, they're
orphaned). With computers having 2GB, or more, of system memory, the
memory footprint of 50MB or 55MB is trivial (and that 5MB would be a
huge difference acquired after years of use for those orphaned entries).

There is only one time when using a registry cleaner is recommended:
when there is an entry causing a behavioral problem in the OS or an app
but the user hasn't a clue how to find the offender. If, for example,
an app relies on a registry entry that points to a no longer existing
executable then it should error and gracefully recover but instead the
app may instead crash (i.e., a crappy app authored by a lazy or ignorant
programmer, like not testing the return status of a function call and
merely assuming it worked). I've seen where the context menu for an
object, like a file or folder, will cause an error or crash of Windows
Explorer but cleaning the registry will eliminate that problem. Often
this is the result of an incomplete uninstall (the programmer coding the
uninstaller or the actions for an uninstall program they use leaves
behind remnants in the registry). We all know how sloppy are many
uninstallers. Changes made to the registry or file set after the
uninstall are unknown to the uninstaller which created a log of the
install to know what to uninstall. The changes made after the uninstall
won't be in the log. Sometimes programmers don't remember or don't know
about some things they should be removing or replacing during an
uninstall. So you end up with a remnant shell extension that causes
Windows Explorer to crash when you right-click trying to bring up the
context menu. In those cases, often it is easier and faster to run a
good/safe registry cleaner than dig through the shell extensions or
namespaces defined in the registry.

Despite the ease of using a registry cleaner, YOU are still the final
authority as to what should be removed or changed. If the registry
cleaner doesn't list its proposed changes then it's a **** tool that
should itself be uninstalled. Once it shows its proposed changes, YOU
are to review that list and decide what it should do. If you don't
understand the proposed changes then don't allow them; however, if you
don't understand the proposed changes then you shouldn't be using any
tool to clean out the registry. The registry cleaner facilitates what
you should be capable of doing yourself in manually cleaning out the
registry.

In the right hands, and with proper preparation before use, good
registry cleaners are just another expert tool to administer an OS.
Alas, registry cleaners are often designed for use by boobs. It's like
leaving a loaded handgun sitting on a dresser in a home with toddlers.
Ooh, shiny, let's play bang-bang.

On Sun, 31 Aug 2014 21:05:49 -0400, Mayayana wrote:

| What was the timestamp on the unlocked temp file that didn't get deleted
| by the Disk Cleanup wizard?

A few hours. So you may be onto something. I'd consider
that a bug, though. If the file is not open there's no reason
for it to be something that's still to be used. That's why it's
the "Temp" folder, after all.

It is my understanding, bolstered by observation, that sometimes an
installer or uninstaller will leave something in a temp folder and a
RunOnce entry for it in the registry for the next restart, so as to
finish the (un)installation at boot time.

That item should be left in place long enough to do its job.

I have no idea whether that file can be protected.

--
Gene E. Bloch (Stumbling Bloch)

| A few hours. So you may be onto something. I'd consider
| that a bug, though. If the file is not open there's no reason
| for it to be something that's still to be used. That's why it's
| the "Temp" folder, after all.
|
| It is my understanding, bolstered by observation, that sometimes an
| installer or uninstaller will leave something in a temp folder and a
| RunOnce entry for it in the registry for the next restart, so as to
| finish the (un)installation at boot time.
|
| That item should be left in place long enough to do its job.
|
| I have no idea whether that file can be protected.
|
I find installers often leave things but then don't set
a deleter for reboot. That was the case here. Either way,
the files/folders won't be locked because the installer has
quit. But deleting them does no harm.

Mayayana wrote:

| A few hours. So you may be onto something. I'd consider
| that a bug, though. If the file is not open there's no reason
| for it to be something that's still to be used. That's why it's
| the "Temp" folder, after all.
|
| It is my understanding, bolstered by observation, that sometimes an
| installer or uninstaller will leave something in a temp folder and a
| RunOnce entry for it in the registry for the next restart, so as to
| finish the (un)installation at boot time.
|
| That item should be left in place long enough to do its job.
|
| I have no idea whether that file can be protected.
|
I find installers often leave things but then don't set
a deleter for reboot. That was the case here. Either way,
the files/folders won't be locked because the installer has
quit. But deleting them does no harm.

The PendingFileRenameOperations registry key can rename, move, or copy a
file to replace one that was inuse by the OS or some process. This
registry key is used early in Windows startup to ensure the file won't
be inuse (locked) when it is to get replaced by the one specified in
this registry key. However, that commits a single action (on a list of
files). It cannot, for example, do a replace operation on a target file
and then follow with a delete the source file. It isn't used for
running a script of commands. Also, a smart setup program (and any
using MSI) should notice that this registry entry is not empty (nul) and
respond with "Setup has detected that another program requires this
computer to reboot". Files and actions defined in this registry item
require a reboot and should not get mixed in with another
[un]installation.

http://msdn.microsoft.com/en-us/libr...(v=vs.85).aspx

That tells you how to use the MoveFileEx system function call to move
(replace) or delete inuse files or those that must replace system files.
The syntax of the data value for the "PendingFileRenameOperations" data
item under HKLM\SYSTEM\ControlSet001\Control\Session Manager is
"targetfile sourcefile". If sourcefile is non-blank, it replaces
(copied over) the targetfile. If sourcefile is missing (nul) then
the targetfile gets deleted. "Rename" in this data item's name is
misleading. It doesn't rename. It moves, copies, or deletes files (and
folders, too). Some more info at:

http://www.symantec.com/connect/arti...ame-operations

Some installers will continue running (get loaded) after a reboot of
Windows so they can cleanup their files (that will replace others). Yet
too often many installers will exit, Windows gets restarted, but the
installers doesn't run again after the reboot. They don't use the
RunOnce key or WinLogon event to restart themself after a reboot so they
can do cleanup subsequent to the reboot. So there's nothing left of the
installer to do the cleanup of the source files used to replace others.
However, those source files (no longer needed after reboot completes)
will get deleted by anyone or anything, like a disk cleanup tool. It's
just that they should not get deleted until after the reboot. If you do
the install, do a disk cleanup, and then reboot then the source files
will be missing and the install is incomplete so you have old files that
were meant to get replaced but weren't. The result is the OS or app may
misbehave.

Some installers cannot kill their own uninstaller program. The program
is running so its file(s) is(are) inuse although they may not be locked
at the moment. They have to use the PendingFileRenameOperations
registry entry to do the cleanup after a reboot of Windows. For
example, I just tested the Pocketknife Peek add-on for Outlook but then
realized it is available only as a 32-bit add-on and I have Outlook 2013
x64 installed. So I uninstalled Pocketknife Peek. It was a very clean
uninstall yet its au.exe uninstaller program cannot delete itself
because obviously it was running and that executable file was still
inuse. So I currently have PendingFileRenameOperations listing au.exe
(under a randomly named subfolder under %temp%) and the folder also
listed to delete those on a reboot of Windows. You have to open the
data item (double-click on it) to see every file or folder specified as
the regedit right-panel data item pane won't show what's after the 1st
entry. The file is no longer in use since the uninstaller program
exited long ago. I could manually delete it now and either let
PendingFileRenameOperations fail on the next reboot or nullify that data
item's value in the registry. I'll just leave it sitting there and let
the next reboot do the delete; however, I run CCleaner often enough that
it'll probably get deleted before the PendingFileRenameOperations action
gets around to trying to delete (what would then be a file and folder
that no longer exist).

There is some way to have a running program deletes its own file. For
any program to run means it has to be loaded into memory and the
dispatcher passes control to that image in memory. If the entire
executable can be loaded into memory, it doesn't need the file anymore.
One trick, I think, is for program1 to load into memory and then start
program2. Program2 deletes program1's executable file and program2
exits. Since program2 is no longer running, program1's process still
running in memory can delete program2's file. More methods are
mentioned at http://www.catch22.net/tuts/self-deleting-executables.
Expertise varies amongst programmers and often they rely solely on what
the pre-packaged installer will do itself; i.e., the programmers code
for functions the installer program will do instead of create their own
custom installer for each product. They reuse rather than reinvent. If
the uninstaller doesn't delete its own temp files (using one of the
inplace techniques mentioned in the tuts article or via a reboot using
the registry entry), the "installer" programmer won't know until
notified and even then maybe he won't do anything more than what the
installer software lets him do.