XnView Software

I wrote a autohotkey script to set all the dates to the current date. If anyone wants this, you can get it from my github.
It will successfully unbork any borked images.

No, the original extension is lowercase.

That's it! I did the same test. I used FC and changed the Created and Modified dates - which were what got borked - I believe from the drag-n-drop process between FreeCommander and XnView MP (in my other thread). Obviously, 1899 is not a valid date.

When I changed them to today's date, voila! XVI32 ...

Well, I did it again. I exported an image as png from photoshop. Then, from my file browser, I *moved* it into MP. Borked.
Then I did it again.
Then I tried moving the file into MP from Explorer instead of FreeCommander and it didn't bork. Maybe I should open a thread in FreeCommander. Maybe ...

Hi, Pierre!

Here are screenshots.

Alright, so here is a collection of borked images in a zip file.

http://www.sspxusa.org/temp/borkedimages.zip

Now, these are also borked in Classic XnView, and unreadable by XVI32.
However, FreeCommander can view it in its own hex editor. FreeCommander can't view the image though, although it can ...

Okay, I still have the two files I attached above.
I put them in a directory using a file explorer and have not opened them ever with MP.
Again, I can't open them with AptDiff 1.6 - "the parameter is incorrect" - forever.

Now, on my machine, the file named borked.jpg can be opened with XVI, but ...

When you rename a file that already exists, you get the file replace dialogue afterward.
Is there a setting to make the default for the extension to be lower case? Right now the default is uppercase and I have to change it every time.

Okay, so after deleting the dbs, now drag-n-drop seems to work correctly (see my other thread), and can't seem to bork anything else.
Maybe that was the problem. I still have a bunch of borked images, however. MP won't read them still.

The thumbs.db was 6GB in size - and created in 2013.
Maybe that ...

I deleted MPs db files in Roaming, and it seems to have cleared up this drag-n-drop issue for now.
The thum.db was 6GB and the xnview.db was 13MB.
Now the drag icons seem to appear correctly.

Deleteting XnView.db + Thumb.db and then completeley deactivating all cache functionality ( T ools → Settings... → Catalog → Catalog → Enable thumbnail caching ) makes no difference either?

You won't believe this.
So I disabled the cache and exited MP.
Then I deleted the .dbs in the Roaming ...

Normally, I use the dialogue box to rename files.
But if I name a file to a name that already exists, the dialogue still closes then another dialogue appears asking me to either replace the file or rename it.

For example:
I rename a file to myfile1, and push okay. The dialogue box closes.
Another ...

No, I don't think so. It only happens in certain cases and I don't have any other problems with my machine.

But look at this thread: http://newsgroup.xnview.com/viewtopic.php?t=36273
There I explain a problem with drag and drop that can sometimes corrupt an image.

My primary File Browser for Windows is FreeCommander - it has dual panes and I love it (am beta-tester).
Also, I use three monitors.
So, FC is on monitor 1; MP is on monitor 2.
When I drag-n-drop a file (holding shift for move) from FC to MP across monitors, MP does not completely recognize what is ...

Maybe, but I deleted all the cache.... there is no database...