[fixed] 1.92: XnView doesn't always restore associations

[ckv]

I some cases XnView doesn't restore previously replaced associations when using the "Restore All" button.

This bug is a little hard to reproduce and I don't know if it only occurs when using the button, but it appears that the backup restore fails only when "View as Name" is selected in the associations page. The best way to reproduce this bug is to simply use the "Add All" button and then restore the associations with "Restore All" button while "View as Name" is selected.
Better do this on VM or backup the associations that you know are going to be replaced.

I tried this couple times on my win2k VM system and when "View as Extension" was selected XnView restored all the replaced associations successfully, but while "View as Name" was selected it didn't restore all the replaced associations.

[ckv]

Still reproducible in XnView 1.93.6

Here's how to reproduce for the brave:
- Go to associations page in options.
- Click "Add All" button.
- Restart XnView.
- Go to associations page in options.
- Select "View as Name".
- Click "Restore All" button.

Result: XnView doesn't restore all previously replaced associations. I don't mean the association list in XnView I mean the actual associations in Windows registry.

On my case it didn't restore .bmp, .clp, .dcx, .ico, .jfif, .jpe, .jpeg and .jpg associations. But this will naturally vary system to system depending on what associations exist before creating the associations.

I still recomend using Virtual Machine to try this or at least manually backup your associations.

[xnview]

Ok, i'll check

[xnview]

I've tried but i have correctly all previously associations.
For example, for .bmp or .clp what was the previous value?

[ckv]

.bmp = Paint.Picture
.clp = clpfile
.dcx = DCXImage.Document
.ico = icofile
.jfif = pjpegfile
.jpe = jpegfile
.jpeg = jpegfile
.jpg = jpegfile

I still have the .reg files from HKCR key taken before and after creating and restoring the associations. Not sure if those can help, but you can get them frm here: *snip*

[xnview]

I've tried on a fresh win2K isntall, and all associations are restored correctly

[ckv]

I've tried on a fresh win2K isntall, and all associations are restored correctly

Did you use "Add All" to create the associations?


Here's what I think is causing this bug...

All the file extension that fail to restore are all under more than one name. E.g. .bmp is under Windows Bitmap, OS/2 Bitmap and Alpha Microsystems BMP

When "View as Extension" is selected this is no problem cause each extension is listed only once, but when "View as Name" is selected some of the extensions are in the list more than one time. Because of this those extensions are also processed more than one time.

So when restoring associations. The first time the extension processed, it restores the previous value successfully, but for the second time (for some reason) it still trys to restore the association and breaks it cause the bakup key doesn't exist anymore.

I took this Regmon log while restoring the associations. First the .bmp extension is restored successfully (line 772), but later on it's restored again (line 9389 and line 15665) and a null string is writen as value for .bmp
*snip*

[xnview]

I've tried on a fresh win2K isntall, and all associations are restored correctly

Did you use "Add All" to create the associations?

Yes

I took this Regmon log while restoring the associations. First the .bmp extension is restored successfully (line 772), but later on it's restored again (line 9389 and line 15665) and a null string is writen as value for .bmp
http://koti.mbnet.fi/vaultec/files/regmon.zip

I'll check again...

[xnview]

Ok, will be fixed in 1.94 beta 2

[ckv]

Ok, will be fixed in 1.94 beta 2

Not a one smile post

[ckv]

Ok, will be fixed in 1.94 beta 2

Confirmed. Fixed in 1.94 beta 2.