jv16 PowerTools 2007 RC2 released

tullik

Backup Tool, file and directory restores

Questions:

Are requested file and directory restores always successful?

If not, shouldn't the failures be indicated in the message box? Perhaps they would be, but I have not seen any …

For example, when I restore a backup twice, one right after the other, I would think every file should fail the second time …

tullik

Registry Cleaner - a missing field in the Vista registry?

With both PT2006 and PT2007 RC2, the date column shows with an XP registry, but does not show with a Vista registry.

See original post by new member BRHess …

blackdex

Hello,

I Had some probs with the registry compactor.

When i run the tool, and didn't reboot right after it.

Then i run the compactor again, and it gave me almost the same results as the first time, like it never had been run.

The strange thing is, this doesn't happen every time.

And also, i have closed all apps when i run the compactor.

jv16

BlackDex wrote

I Had some probs with the registry compactor.

When i run the tool, and didn't reboot right after it.

Then i run the compactor again, and it gave me almost the same results as the first time, like it never had been run.

This is because the registry is compacted, but the old non-compacted registry hasn't yet been replaced with the new compacted registry. This is only done during a reboot.

jv16

tullik wrote
Backup Tool, file and directory restores

Questions:
Are requested file and directory restores always successful?

If not, shouldn't the failures be indicated in the message box?

You are correct, the restoring of a backup could some time fail due to access problems, for example.

For example, when I restore a backup twice, one right after the other, I would think every file should fail the second time …

I wouldn't call that a failure since all the backuped files were restored in way they are all back. But if it wouldn't be possible to restore a file because there are no write access to the directory, that would be a failure.

This will be fixed in RC3. Good one Tullik!

tullik

Backup Tool, file and directory restores

jv16 wrote
tullik wrote … For example, when I restore a backup twice, one right after the other, I would think every file should fail the second time …

I wouldn't call that a failure since all the backuped files were restored in way they are all back. But if it wouldn't be possible to restore a file because there are no write access to the directory, that would be a failure. …

Yes, "fail" is the wrong word, and is not really what I meant. I was thinking along these file integrity lines:

1. The job of the Backup Tool's restore function is to put one or more files back at the original location, where location is defined by the original directory path of each file

2. For a given filename (say, for example, File-N), there are two cases:
- a. File-N does not exist at the target location -- it should be restored without a doubt -- no message is called for unless an access or other real failure occurs
  
  b. File-N already exists at the target location -- there are two cases:
  - 1) The backed up File-N is (apparently) the same as the File-N at the target location (same size, same checksums, same whatever can reasonably be checked). It can be restored; if it is certainly the same, the actual restore could even be skipped -- no message is called for unless an access or other real failure occurs
    
    2) File-N at the location is clearly different than the one backed up. Something has happened since the backup was made; perhaps some process recreated File-N -- it is not certain that the backed up File-N should replace the different File-N -- an informational message should indicate File-N was not restored because a different one already exists (this implies an override restore mode would be needed if the user, after investigating, decides to restore anyway)
3. I don't know if the Backup Tool restore function is capable of doing all these things -- in any case, I'm pretty certain they won't be in PT2007 Release 1 ...

What triggered this convoluted thinking? This report: http://www.macecraft.com/phpBB2/viewtopic.php?p=9504#9504 -- History/MRU Cleaner, unadvised backup

Of course other potential risks to file integrity could exist besides that allegedly unadvised backup.

jv16

tullik wrote

3. I don't know if the Backup Tool restore function is capable of doing all these things -- in any case, I'm pretty certain they won't be in PT2007 Release 1 ...

When you restore a backup and the File-N already exists at the target location jv16 PowerTools deletes the File-N and copies the backup file to its location. This ensures the file after restoring is the original.

If the file deletion fails, the PT starting from RC3 will show an error message.

tchapaiev

When running One click disc cleaner , there are options which should prevent in priciple cleaning necessary or vital temp files ; at least give the user CONTROL over what he is doing ; BUT as I already mentioned a curious phenomenon occurs ; you are first presented with the option of taking a backup of will- be deleted files; which is a good and useful functionnlity ; then you preform the analysis by clicking start ; at the end of that process , instead of beeing presented with a list of UNCHECKED files which you may delete or not at will , you are presented with a list of CHECKED AND ENTLIGHTENED LIST OF OBJECTS which appears very shortly so that you can't really see what will be deleted and the deletion process begins immediately while the window : "other options" shows up without any possibility to choose what you want to do ; instaed ,when the work is done ; you may eventually edit the bacjup and restore what you wish ; firdt of all , this procedure is not explained (you are just put in front of the posssibility to wreck down your PC , how nice!) and secondly the window "other options remin useless ! Could you please change this before launching the final version ???

tullik

tullik wrote
... About a dozen files "Failed to remove" because "The process cannot access the file because it is being used by another process." These files were backed up (which is not a real good idea for an open file -- a later restore could wipe out changes ...).

jv16 wrote
… When you restore a backup and the File-N already exists at the target location jv16 PowerTools deletes the File-N and copies the backup file to its location. This ensures the file after restoring is the original. …

It is sort of a two-phase commit thing -- if you can not remove the file just backed up, then you should remove its backup …

jv16 wrote
... If the file deletion fails, the PT starting from RC3 will show an error message.

The file may no longer be in use when you do the restore, but the file may be more current than the one unconditionally backed up …

jrd1st

@TCHAPAIEV- Maybe I'm wrong, but isn't that the whole idea of "One Click"; to be able to get it done without going through a lot of steps? I thought the user was supposed to just set it up once and run it with those settings as needed.

elazor

Sorry, we encountered an error while displaying this content. If you're a user, please try again later. If you're an administrator, take a look in your Flarum log files for more information.

piaqt

@ elazor: Trying to teach forum posters to spell is, at best, a Sisyphean effort.

elazor

xxx

tullik

This current discussion trend has little to do with PT2007 RC2 testing.

I suggest you move it here: http://forums.delphiforums.com/dictionary/start

blackdex

jv16 wrote
BlackDex wrote

I Had some probs with the registry compactor.

When i run the tool, and didn't reboot right after it.

Then i run the compactor again, and it gave me almost the same results as the first time, like it never had been run.

This is because the registry is compacted, but the old non-compacted registry hasn't yet been replaced with the new compacted registry. This is only done during a reboot.

I didn't explained it very well i see.

I know that i have to reboot before it realy takes affect.

And that is what i did.

Follow thrue:

1. Run compactor.

2. Normaly close PT

3. Now do something like go to start > run

4. Then just reboot the computer.

5. ReRun the compactor, and it shows the same result.

This is what i did.

Again, it doesn't happen all the time for some strange reason.

jrd1st

@BlackDex - what are those results? If your registry doesn't really need to be compacted, then maybe what you're seeing is the result of a small amount of "de-compaction" from the reboot.

If you have a large amount of compaction shown each time, then perhaps you have a problem.

elazor

xxx

jv16

Here are the results of bug fixing of the RC2 done since the last report. Notice that the Reported by field means the user who was the first to report the problem. If there are errors in these reports, please let me know since these are used when it is decided which users qualify for the free personal license.

Issues found by beta testers

Issue: Entry last modified data is not visible in Registry Cleaner under Vista

Reported by: BRHess