FD-ISR ~ ShadowUser -> engaged!

dallen,
Do you have any idea how much work that will be to nail this problem, if you don't even know where to start.
At work, I have the computer department to solve these problems in detail, I only report the problem, I don't solve the problem, that's their job.
At home, I don't have all that and I certainly don't have 8 hours freetime.

 

ErikAlbert,
I certainly appreciate the complexity as well as the value of your free time. However, these forums are all about learning and helping. We all learn from you, just as you learn from us. You have been very helpful with your input. The only reason I made those comments were to suggest that since you seem to be the only one that has discovered the problem, you are probably the only one that can help fix it. You are certainly not compelled to help, but you help would be greatly appreciated, as it always is.

 

ErikAlbert,

I appreciate your entry, and I recognize a lot of what you are saying.
I have a strong drive to understand how things work, so I'm not focused on finding limits and errors, but on getting a complete idea of options.
Maybe it's because of my understanding of options that I'm never able to reproduce the errors that regular users 'create'.

Anyway, it is my understanding that you were trying to freeze more than one snapshot, and perhaps you passed the limit of options there.
I don't know the details, but I have the feeling that the 'freeze' is just a single archive with hardcoded name that is assigned to be the reference of one frozen snapshot. Somehow things might have gone wrong when you tried to tie more than one snapshot to that specific archive.
I'm only saying this to help you with some idea's, I can see that you are unsatisfied with an error that slipped away.

Thinking of this, why not change the freeze concept in a way that you are able to assign any archive to any snapshot as freeze reference. Updated at boot time of the active snapshot.

 

The only one? I wouldn't be so sure about that.
Not every FDISR-user reports problems, if he found a solution to fix it. Why would he spend time on reporting, if the problem is already fixed?
Not every FDISR-user is an active member at Wilders either.

My FDISR-problem was easy to fix, I recovered the last ATI-image backup and I got both FDISR-snapshots back on my harddisk.
So I could have kept my mouth shut and keep every FDISR-user happy, but that's not my style.
Maybe you don't want to hear anything bad about FDISR, because you love it.
Loving software means usually that you accept its disadvantages and failures or don't even want to see them or talk about them.
I don't love FDISR and when it fails I like to talk about it, even when I'm not able to prove it and in that case it's more a warning for other FDISR-users and Raxco.

 

IT DOES??!! I am very familiar with this product but I would like to know the procedure to do this.

Acadia

 

That's easy. Merging snapshots is the same as refreshing and refreshing isn't used by FDISR either, FDISR calls it "copy/update".
Merging or refreshing? I'm not going to play word games in a language that isn't my first language. Is it that important?

 

In this case, YES, you threw me for a loop! I was thinking of merging the way that PartitionMagic can merge partitions, and could just picture a version of WinXP with Norton Anti-Virus trying to merge with a WinXP that has McAfee: WAR!!

Acadia

 

LOL. Sorry for using the word "merging". I probably don't know what it really means. I ment "refreshing". I will change it if I 'm still able to edit the post.

 

Nah, forget it, no need to edit, thanks.

Acadia

 

dallen, I don't think bigamy, or polygamy for that matter, has been outlawed in the state of cyberspace -- or are you just that much of a romantic ?

Myself, I tend to subscribe to the K.I.S.S. principle, but the temptations to redundancy are ubiquitous !

 

Merging means adding together while eliminating any duplication.

"Refreshing/Updating" would include deleting from the target snapshot what is not present in the source snapshot and, hence, would only be equivalent to a merge if all the contents of the target snapshot were still present (with identical attributes) in the source snapshot. Even at that, I guess one could argue strictly that, after a true merge, only one snapshot remains.

 

Thanks for explaining it and merging was indeed the wrong word. Meanwhile, I also looked it up in my dictionary.
I understand Acadia's reaction better know. LOL.

 

I can imagine why not many people use the freeze function.
The freeze function isn't practical enough and freezing is very slow compared with any other FDISR-action and requires double space.
If it was a simple button to freeze/unfreeze an active snapshot, than it would be used more often.
It is just an option for a specific group of users, that need it constantly.

 

Erik
That certainly makes sense. I must admit I'm pretty ignorant of freezing in FDISR. Seems like it would fill a very specific need.

As for my explanation, it's good you took it the right way. Weet je, mijn vrouw is van Brugge, West Vlaanderen. So, I kind of do that reflexively after 22 years of training.

 

By saying only one, I should have been more precise. What I meant was that the only one that I've heard.

And not every FDISR-user is a "He." I know what you meant, but if you are going to pick through my statements with a fine tooth comb and argue every minute detail, then this will turn into a very long thread.

Don't you think that if a FDISR user had a problem that was of any signifigance at all that user would seek out help in the official forum? Addidtionally, if the problem was at all prevelant, then wouldn't at least one of the users have posted about the problem here? Since I read a lot of the threads in this forum, don't you think that I would have read at least one of the other user's postings about the issue at some point? My point is that the problem that you MAY have found, is very unique. I say "may" because the issue that you discuss without any evidence may have occurred as a result of something totally unrelated to FDISR. Just a thought for consideration.

No one wants you to "keep your mouth shut," or more precisely keep your fingers from typing and nothing that I've said should have given you that impression. It's not that I do not want to hear anything negative about the software that I make love to...I mean love, or as you would prefer to say "like." I just want negative comments to have substance. I want negative comments to be substantiated. That being said, how much is it to ask that you first consider the possibility that you've either encountered a very obscure bug that does not impact many people (still worthy of research of course) and second consider the possibility that something on your system may be the cause of that problem. Even if this is not the case, not being able to substantiate your claims does not do much to add credibility to your allegations.

ErikAlbert, how is it that you complain about people when they misunderstand your use of the language and demand sympathy because Engish "is not your first language," but you are quick to play symantecs with other user's words? Does this seem fair?

Furthermore, your warning to FDISR-users should read as follows:
FDISR users, I am the only one that has experienced this error and taken the time to report it. I cannot tell you what caused it. I cannot replicate it. It may or may not have been caused by my specific system, but caveat empor.

Personally, I think that you are violating your own rule when it comes to loving software and you just won't admit it. Psst...come on you can tell me. I won't tell anyone, I promise. You are married to ATI aren't you. You just don't want FDISR to know because you have a crush on her, don't you?

 

Hello FDISR-users,

If you open "PerfectDisk" and
click on Tools / Advanced Configuration / General Settings tab

Optimization of files needed to start your computer (blue chapter), which has 4 options
1. Let PerfectDisk manage [recommended]
2. Let PerfectDisk manage all the layout.ini files (Windows XP only)
3. Let Windows manage the layout.ini files (Windows XP only)
4. Disable

The first option was marked in my screen.
IMO this starts an automatic defragmentation, if necessary. I've seen that icon was running, analyzing my HDD

If true, this could have caused my troubles with FDISR, while I was freezing an ACTIVE snapshot AND an accidental defragmentation was running.

What do you think? Is that possible?

 

This is definately better, IMO. My primary concern is your use of the word "could." Assuming that the conditions that you listed are accurate, one would have select the settings you chose, freeze an active snapshot, have sufficient fragmentation of the hard disk to trigger the automatic defragmentation, and hope lightning strikes.

Of course if the error occurs even only one time out of a thousand under these conditions and is due to FDISR, then that is unacceptable and needs addressed.

You end by asking "Is that possible?" The answer to that question almost always "Yes." However, merely making up a scenario and asking if it's possible does little to substantiate your claim. Your claim is that FDISR has a bug, correct? Are you telling us that the aforementioned conditions are the very conditions that triggered the error? It seems not. It seems that you are presenting a scenario and asking if it is "possible" that such an error could have occurred under the cirucumstances presented in the scenario. Of course it is possible. My question to you is "Did your error occur under the scenario that you mentioned?"

 

IMO, selecting number 1 does NOT start an automatic defragmentation. It simply sets HOW PD defragments when it does. When PD defragments is determined either by the user manually launching it or by Windows Task Scheduler running it automatically (after the user sets it up to do so, either through the PD interface or throught the generic Windows interface).

I've been wrong before but I think you should double check that observation and your interpretation of it.

 

I seriously doubt that, ErikAlbert, for the following reason:
Both Raxco PerfectDisk and Raxco FirstDefense-ISR rely on the Windows API for any disk access. There are absolutely no tricks under the hood.
If is it possible that PerfectDisk moves a piece of the Freeze Storage.arx file while that same file is created by FirstDefence, then still it wouldn't break, because Windows ultimately takes care of the disk access.

 

Well, an automatic defragmentation by "PerfectDisk 7" on reboot causes indeed ERRORS when you are freezing an active snapshot at that moment.
I was able to create such a situation again and I had a freezing with Errors=653.
I still have to read the latest posts in this thread but I'm busy right now. I'm back within a hour.

 

Hi guys,
I'm back after helping wife doing the dishes. Two magic words guarantee a long marriage : "Yes dear."

I have sent an email to the technical support of Raxco.
Not really as a bug, I just told them my story and my opinion about this.
I also asked them how to stop this automatic defragmentation, because I'm not sure which setting causes it. I like to hear this from Raxco itself.

I also told them, that when an user starts a freezing in FDISR, that FDISR itself has to stop any defragmenting, before the freezing is executed in order to guarantee a freezing without errors.
Less-knowlegeable users do NOT relate a bad freezing with defragmentation.
They think the problem is FDISR, where the error occurred, not PerfectDisk or any other defragmenter.

The first time when this error occurred I didn't pay much attention to what I was doing.
Why I did miss the error warning of a bad freezing, I don't know. Maybe I closed this message. I was doing several things at the same time, too many open windows and this could have happen.

The last time however, I was in control and watching everything and freezing ended with Errors=653 and the PerfectDisk-icon in the system tray indicated that a real defragmentation was running, which was not started by me.
I would never start a defragmentation myself during a freezing.
So this time, I can prove it and of course every FDISR-user can do this test himself, but backup your harddisk first, when you try this.

I saved the detailed Activity Log in case Raxco needs it.
It didn't sent it as an email-attachment to Raxco, because its size = 6442 KB and I don't know the limit of the size of email-attachments.

Is this a bug? I leave that judgement up to Raxco. IMO it's not a bug, but FDISR should never allow a freezing while a defragmentation is running OR stop the defragmentation.
FDISR can at least stop PerfectDisk, because Raxco created both products. I don't know about the rest of third party defraggers, but maybe it's possible to stop them as well.
So I don't fully agree with Peter, that users have to configure any settings to avoid a bad freezing combined with an automatic defragmentation.

I appreciate your co-operation in this matter.

 

ErikAlbert,

It must be a relief for you to get a better understanding of what happened, good for you!
I know that other defrag software (like diskeeper and MST) have an option to only defrag when there is no disk activity.
But you are right, when you use your software in a normal way, you would never suspect that some combination of activities would lead to serious problems like you encountered.

I'm actually surprised by you findings, I had the understanding that both software used the reliable Windows API.