Re-freeze vs. Freeze/Unfreeze

If you are booted in a frozen snapshot and you use the function Freeze under "Actions",
the frozen storage (Freeze Storage.arx) is also updated, I call this "re-freezing".
Upto now I always used this method, but I noticed that it doesn't work always properly as I expected.
I had two problems :
1. Look'n'Stop asked each time for authorization of Thunderbird, when I opened Thunderbird for the very first time, which wasn't really an error, but very annoying. After I authorized, I re-freezed the snapshot to remember the authorization, but that didn't work. After reboot I had the same thing.
2. Look'n'Stop also asked for authorization of Prevx1. Re-freezing didn't help either.
It has probably something to do with Look'n'Stop.

Solution : I unfreezed the snapshot and freezed it back and that worked properly.
I can't explain why FDISR didn't update the freeze storage during re-freezing and this was not supposed to happen.
Re-freezing = freeze + update and it seems to work for other things, but not in this case.
Straight from the FDISR manual :

This is a warning for frozen snapshot users : you better use "unfreeze & freeze" than "re-freeze".

 

Yep, dipped my toes in the icy waters of frozen snapshots (bad pun intended) and got exactly the same result.
What would be interesting to know if we see the same 'problem' with other security softwares or if this is purely a L'n'S peculiarity.
I can't see an obvious reason why L'n' S should forget the authorization unless FD-ISR is not updating all parts of the system during the re-freeze procedure, but does fully update with the 'unfreeze/ freeze' procedure.
I doubt it's a security worry but maybe it has the potential for generating some software glitches....

 

Firstly, thanks for confirming it, which means my observations were correct.
There is obvious a difference between re-freeze and unfreeze/freeze that has been proven.

LnS also lost its Application Filtering Settings CHANGES and most probably all the rest in the settings WITH RE-FREEZE.
So the problem is bigger than just the authorization of Thunderbird and Prevx1
All other applications didn't have that problem and they are also controlled by LnS.

IMO it can't be LnS otherwise the "unfreeze/freeze" method wouldn't work either and this means that all LnS-objects are stored normally in the snapshot and not somewhere else.

There must be a difference between "Freeze" alone and "Unfreeze/Freeze". Maybe the "Unfreeze" does something that is required for having a good "Freeze". Beats me.

 

I can't reproduce the problem anymore via restorations of 1-2-3 days back and it's fixed in my current snapshot.
Maybe when I re-freeze as a regular method again, the problem might arise again some day. I will keep an eye on it.

The problem disappeared after unfreeze/freeze without disabling LnS, so LnS can't be the reason.
The only difference is "unfreeze" in both methods, which isn't used in the re-freeze method and that's where the "update" failed. This is abnormal and contradictory with what the manual says.

 

This gets more interesting.....
Tried it again after updating a couple of programs and this time SSM wanted to recalculate the checksums (as it would normally) but after refreeze it asked to do it again, which it didn't do with 'unfreeze/ freeze'.
See, ErikAlbert, there is a valuable use for all these talkative HIPS with their cryptic messages- they let you find out there's something funny going on with refreezing in FD-ISR...

 

Yes indeed and I'm glad LnS isn't the only one.

Maybe we can use the Activity Logs of FDISR to prove the difference :
1. export the detail Activity log of Refreeze
2. export the detail Activiy log of Unfreeze
3. export the detail Activity log of Freeze.
All these logs can be read with Notepad.
If report-1 and report-3 have crucial differences, we can report it to Raxco.

A smaller frozen snapshot with much less softwares on it, might be easier to nail the problem.

 

Sounds a good idea.
Am away for a few days will test out on my return and post results.

Lee