* Unable to display dialog for External File Links

[AdrianBruce]

Anyone have any idea what might be happening here?

I'm trying to use menu item Tools / External File Links and when I select the option all I get is an error message "Unable to display dialog".

Tools-ExternalFileLinks.JPG (15.16 KiB) Viewed 11097 times

I haven't tried all other dialog boxes in FH but I've tried several, especially in that Tools menu and they all work.

FH V6.2.2
Windows 10 Home, v1607, Build 14393.693

I suspect it'll be a Calico Pie job on Monday but on the off chance that someone's seen this...

[tatewise]

I have vague inkling of seeing that before but cannot recall any details.
Is everything else as normal?
Is it meant to be a Project and does it say Family Historian Project atop the main window?
Are media images displayed in the Focus Window, in Media tabs, in the Media Window?
Are your media usually stored within the Project Media folder or elsewhere?

[AdrianBruce]

Is everything else as normal?
So far as I can see, yes.

Is it meant to be a Project and does it say Family Historian Project atop the main window?
Yes and Yes

Are media images displayed in the Focus Window, in Media tabs, in the Media Window?
Yes to all 3 on the samples I tried.

Are your media usually stored within the Project Media folder or elsewhere?
Yes and on the Media tab, when I sort into File (name) order, all the Filenames show that.

Oddly, the menu item Tools / External File Links works perfectly for the Family Historian Sample Project, which seems to blow away my idea that a bit of software had got corrupted when I installed... Well, who knows what I've installed since I last used this menu item.

The only mildly odd thing I've done a day or two ago was delete the ThumbCache.dat for this project, which I've done in the past. (Project data is all in Dropbox but I've let Dropbox finish its sync before reopening FH and retrying - still fails.)

Need image of Stan Laurel scratching head in puzzlement.

[tatewise]

It does begin to sound more and more like a graphics display issue just for that command.

Such issues seem to be related to interactions between the default Printer and the ThumbCache.dat file.
Which explains why different Projects behave differently.
See problem with Link to Face media (14559).

Try setting the File > Print Setup to use a different printer.
Try the Family Historian PDF first.

Another suggestion is to try and restore the deleted ThumbCache.dat file from the PC Recycle Bin.

Does either get External File Links to work?

[AdrianBruce]

It is something in a .JPG I downloaded from Ancestry very recently....

Wondering if it was some dodgy data, I copied the Project using Project Window / More Tasks and deleted all Media items added during January. The Tools / External File Links menu then worked.

I then recopied the whole thing again to start and this time deleted media items one at a time until the Tools / External File Links menu worked again.

As a cross check, I added the .JPG to the Sample Project and immediately induced a failure in the Tools / External File Links menu.

What is up with the .JPG? I dunno right now....

[tatewise]

Excellent software forensics!

Cannot think it is the image content as External File Links only lists paths and file-names.

Does it have a long or unusual filename of some sort?
Try simplifying it.

Presumably all the Media record fields are sensible: i.e. Format matches filetype of .JPG?

[AdrianBruce]

Doing a right click in Explorer on the PITA file gives this for its properties:

FileModified1943.JPG (43.78 KiB) Viewed 11048 times

Modified 1943? I think not....

I have just re-downloaded the image (under the same name but with "rep" for replacement added) and its file properties are normal, with today's date for created, modified, accessed. I modified the Media record for it in my proper project to point to the "rep" image - so nothing else changed other than that one tag, and everything works.

So whatever the EFL menu does, Mike, must process the file in sufficient a manner to hit whatever corruption it was. The image always displayed happily in Explorer etc,.

Now, the thing is.... that was possible for me for 2 reasons:
1. I understand debugging software;
2. The corrupted file was just a short time ago.

Seems to me that it would have been more than difficult if either of those 2 conditions didn't hold.

I wonder if the error can be trapped by the EFL routine in such a fashion as to identify the corrupt item?

[tatewise]

Excellent - you are right about the conditions.
Hopefully you still have the corrupt file.
I suggest you send it to Calico Pie and hopefully they can sort out the problem.

[davidm_uk]

Could that filename have caused the overall path length limit in Windows to have been exceeded? I can't remember what the limit is, but I'm sure that someone will know?

What happens if you just replace the name (and extension) of the offending file to something very short (just as a test)? I say replace in case there are any hidden "funny" characters or codes hidden in there. Windows may even object to you doing this if it doesn't like the name for some reason.

[tatewise]

David that was my earlier thought, but Adrian has proved that is not the problem, because the replacement file that worked OK had rep added to its filename making it longer.

It was the internal corruption that caused the problem, and disappointingly upset the entire dialogue rather than just the list entry for the image file in question.

[AdrianBruce]

Message sent to Calico Pie.

[Gowermick]

Did anyone notice the 'strange' path location? It looks as if it repeating 'bruce v3 copy' in the path name! Ican see /bruce v3 copy/bruce v3 copy... As one can't see beyond end of dialogue box, does it go on ad infinitum? Could it be this that is causing the problem?

[tatewise]

I repeat: The problem was a corrupt file. Look lower done at its Modified date and read what Adrian says. When downloaded again, with a longer filename it was fine with sensible dates and loaded into projects OK.

[AdrianBruce]

... I can see /bruce v3 copy/bruce v3 copy... As one can't see beyond end of dialogue box, does it go on ad infinitum? ...

No, it doesn't go on forever, that was me not quite realising how the project name and the folder name interacted. When I created the copy (using FH's own Project Copy) I created a folder to put it in, and gave the copied project that same name. What I hadn't realised was that FH also created a new folder to contain the project, so the result was a folder named X containing another folder named X containing the set of individual project folders - I could have just got FH to copy the project into an existing folder, no need to create a new one. (I find this a typical oddity, by the way, not just in FH. I create a folder to put something in and the utility creates a single new folder inside it.)

[AdrianBruce]

Murphy's Law...
The file that I sent to Calico Pie, which causes the issue, loads quite happily into their system and Tools / External File Links works. When I asked what the dates were on their copy of the file, they were all 2017 dates - no 1943. Yes I did send them the right file.

What I suspect happens is this (and I'm making up my own terminology here):
The "payload-data" for this file in my disk is fine because it displays the image OK in lots of apps.

What seems to be wrong is the meta-data, specifically the dates, which show up as weird - either impossible (though validly formatted) values when I right click and show properties, or blank when I look at the dates in Windows (File) Explorer and view columns containing those dates. Of course, the values of the dates may not be what causes the Tools / EFL routine to fail - they may simply be symptomatic of an error elsewhere.

Seems to me that this bit of the meta-data gets reset by the act of writing to "disk"- which is entirely sensible if that's what the dates are supposed to record. So either my attaching it to my email reset the data, or Calico Pie's saving it to their disk reset the meta-data. Either way round, they have nothing to investigate.

So we don't know what exactly made the Tools / EFL routine cough. Which makes it more than tricky to design a fix. And it's certainly impossible to test it for these circumstances. (OK, you can set values artificially in a test rig but we don't really know what values to set!)

I did ask them to see if they could identify a failing media file during the pass of the media files and display that. I have no idea if that's possible - it could be that the error doesn't occur until the end of the pass, particularly if they use a control supplied from outside CP that comes up with a file tree in a single pass.

In lieu of any better suggestion I can only suggest that anyone with this problem examines the file dates of their media files. Maybe do it in Windows (File) Explorer, set to view Details (i.e. not icons) and at the very least show "Date Modified" - my "corrupt" file had Date Modified blank.

[Russell]

Adrian's use of the word 'payload' triggered an unpleasant thought, which has probably already ocurred to others and been dealt with.

But - I presume that the possibility of the image being infected with malware of some sort has been considered and ruled out by the use of more than one scan using different antivirus products?

An outside chance possibly, but having been caught in that way once - and being very grateful for my offline backup files - I perhaps get a little paranoid about any further odd PC behaviour! And just because the file was obtained from a reputable source does not mean that an outside agency has not been tampering without the site owner's knowledge.

It would be good to have a definite cause for your problem established, but perhaps it was just the unusual metadata and some program routines dealt with it differently to others.

[tatewise]

Here are my thoughts:

Try writing a copy of the file to prove your theory about resetting the meta-data dates in the copy.
You are probably correct, but it would nice to know.

Instead of sending the corrupt file, use right-click > Send to > Compressed (zipped) folder, and send the ZIP file.
Then when Calico Pie use Extract All the corrupt file should retain all its original meta-data.
It is certainly the case that the three Dates in Properties are unaffected by the above process.

Calico Pie should know what criteria trigger the Tools > EFL error message, and must have some idea as to what those criteria might be, and how to contain them.

Sounds like they did not reply when you asked "if they could identify a failing media file during the pass of the media files and display that".

Try the ZIP file tactics and keep pressing.
If nothing more is unearthed, then I will add something to the KB on this subject.

[AdrianBruce]

Unfortunately it looks like the Extract process tidies up the meta-data - I can see the duff meta-data inside the .ZIP file but when I extracted it myself, into a temporary area and loaded it into the Sample Project, then everything was OK. It didn't seem to reset dates just ensured that the format was OK for the Tools / EFL routine.

Copy and Paste doesn't seem to re-set the dates, so I'm not sure what the criteria are - only that stuff I download from Ancestry ends up with today's date as the Modified Date (and Created and Accessed I think). Reloading stuff from a back-up seemed to reset Created and Accessed but not Modified. Which means I'm looking at a file (another one entirely) modified in 2014 (download date?) but created in 2016 (restore to laptop from back-up of desktop).

Haven't yet had a response to "if they could identify a failing media file during the pass of the media files and display that", but it was only earlier today that I asked.

[tatewise]

If you were willing, Calico Pie could remote access your PC and investigate directly that way.
But it does sound like it is getting less and less likely that the problem will happen again.

BTW: If copying the file makes everything OK, how did it get copied into your Media folder still corrupted?

[AdrianBruce]

... BTW: If copying the file makes everything OK, how did it get copied into your Media folder still corrupted?

I think it depends on the mechanism used to invoke that copy. (No reason to assume that there's only one routine used!) When I used FH's internal project copy, the bad dates remained bad. Other drag and drop copies similarly leave the bad dates.

Downloading the stuff from Ancestry resets the dates to OK. Unpacking it from a zipped file resets the dates to OK. I think.

It's almost as if Microsoft intended "Date Created" to be "Date Created on this machine" - hence the download from Ancestry normally sets up today's date as did the mailing to Calico Pie and saving there - new machine.

Putting it into a zip file and out again on my own machine is a touch anomalous because when it came back out, the dates were reset - but maybe that lost track of the machine within the zip, so reset.

I suspect that the original corruption happened at the point of writing to my disk because that ought to have reset the dates to "today" - but didn't. I certainly can't remember ever seeing such a problem before. The only thing is - what's the fastest way to find the bad file? Given that my media folder has lots and lots of sub-folders, checking each one for files with odd dates might be time consuming. Alternatively, deleting media records inside FH as per my original diagnostics but doing it in a binary chop - half the media in one go each time! - is about the only other way that springs to mind.

[tatewise]

You comment about the extracted file is different to my experience where using right-click Extract All on the zip file retained the original dates in the extracted file.

Regarding copy techniques, it is possible to transfer meta-data from one file to another after being copied.
I know because some of my Plugin use that feature.

[AdrianBruce]

You comment about the extracted file is different to my experience where using right-click Extract All on the zip file retained the original dates in the extracted file. ...

How strange.