If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Rate Thread | Display Modes |
#31
|
|||
|
|||
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. |
Ads |
#32
|
|||
|
|||
C:\windows\temp cleanup?
| 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. |
#33
|
|||
|
|||
C:\windows\temp cleanup?
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! |
#34
|
|||
|
|||
C:\windows\temp cleanup?
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 |
#35
|
|||
|
|||
Unlocker ( C:\windows\temp cleanup?)
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... |
#36
|
|||
|
|||
Unlocker ( C:\windows\temp cleanup?)
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. |
#37
|
|||
|
|||
C:\windows\temp cleanup?
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) |
#38
|
|||
|
|||
C:\windows\temp cleanup?
| 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. |
#39
|
|||
|
|||
C:\windows\temp cleanup?
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. |
Thread Tools | |
Display Modes | Rate This Thread |
|
|