XnView Software

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

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

A hardware ram fault ?

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.

XnTriq wrote:Deleteting XnView.db + Thumb.db and then completeley deactivating all cache functionality (Tools → 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 folder.
NOW borked.jpg is just fine, but good.jpg is the borked one!
They were the other way before.
Wow, I didn't expect that.

So I put the old dbs back, but it didn't change it back.
borked is good, and good is now borked.

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 will stop future borking.

Now the thing to do is to figure out how to get MP to deal with the borked images.

Brother Gabriel-Marie wrote: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.

Thanks for starting a new topic!

Brother Gabriel-Marie wrote: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 will stop future borking.

I'm sorry to hear that you had to delete your DBs. I sure hope we're only talking about cached thumbnails (which can eventually be recreated).

As far as I know, there have been quite a few changes to the internal structure of these databases since 2013. Maybe a compatibility issue was introduced somewhere along the line.

Brother Gabriel-Marie wrote:XVI32 hex editor will open one but not the other.

Perhaps XVI32 refused to open the image file because it was locked by (one of the instances of) XnView MP?

Brother Gabriel-Marie wrote:Now the thing to do is to figure out how to get MP to deal with the borked images.

Could you please copy an original file and its corrupted counterpart to a different location with a file manager other than XnView and then compare the two again with AptDiff and/or JPEGsnoop?

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 good.jpg cannot.
It's the reverse of earlier.
Maybe I have a disk sector error somewhere? I just installed this HDD a few months ago - brand new WD black.
Funny thing is that I have the same problem on another disk (one only a week old, in fact), so I don't think it's a disk error.
And I've rebooted my computer just yesterday.

Now, I'm doubting whether I named the files correctly.
Either way, one of them is good and one is borked, still, and that's the case no matter which drive I place them.
The files are not locked either - I have a test for that.
jpegsnoop gives the same results as before, it seems.

Maybe I'm the one who's borked.

Brother Gabriel-Marie wrote:Again, I can't open them with AptDiff 1.6 - "the parameter is incorrect" - forever.

I'm still using AptDiff v1.5, and now I seem to remember that I went back from v1.6 because I couldn't get it to run properly.

Brother Gabriel-Marie wrote:Either way, one of them is good and one is borked, still, and that's the case no matter which drive I place them.

I think it's safe to say that we're not dealing with a hardware error (i.e. bad sectors). What I don't get is the fact that the files extracted from borked and non-borked.zip are bit-by-bit identical according to all tools I used to compare them.

Brother Gabriel-Marie wrote:The files are not locked either - I have a test for that.
jpegsnoop gives the same results as before, it seems.

Thanks for checking!

Brother Gabriel-Marie wrote:Maybe I'm the one who's borked.

LOL! You're just fine, Br. Gabriel-Marie

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 with the Imagine plugin; so Imagine is able to view it.

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 something isn't jiving in the information passed between FC and MP.

Thanks for your patience and the new samples, Brother Gabriel-Marie.
I'm doing my tests on a Windows 7 (deactivated UAC) and an XP (admin account) box. As with the first batch (borked and non-borked.zip), I was able to open the images in all viewers/editors I've got at my disposal. So I downloaded XVI32 (which I hadn't used in a while). Lo & behold, it threw an “error opening file” when I tried to load the JPEGs that don't have a (proper) timestamp.

New report just in: JPEG. Can't open .jpeg files

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 had no problem, and ALSO MP could view the file normally!
So, I've successfully gone back and unborked everything! And now that I know what the problem is, I can unbork them anytime I like.

Now, I am quite sure that I borked all these images by dragging them from FC into MP.

I have some other images that are borked, and the even the "Accessed" attribute got borked - FreeCommander doesn't enable the box for me to set that (that is a different problem, different program, however), so I'm trying to figure out how to fix that, too.

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.

Brother Gabriel-Marie wrote: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.

Thanks for sharing!
I remember that (during the Y2K scare in the Windows 98 era) McAfee's “Nuts & Bolts” suite came with a tool for detecting and fixing invalid timestamps of files and folders. I was assuming that CHKDSK is taking care of this nowadays, but apparently it doesn't