Family Historian User Group

Yesterday I attempted to add a Media file to a Source Record, following a routine I have performed thousands of times before. This time I got the message "Media insert failed. Unable to copy file."

I'm aware that a common reason for this failure is overlong file paths, and this has been niggling at the back of my mind since switching to Dropbox for back-up and sync which added a whole new level to the path.

HOWEVER, the file I was attempting to add was named
"Burial WAYCOT Peter 1801 Ashburton GBPRS_DEV_100770275_00073.jpg". The previous day I had added
"Marriage WICKETT MEADEWAY 1657 Widecombe GBPRS_DEV_100771493_00200.jpg" and
"Burial MOUNTJOY Emmanuel 1756 Exeter Holy Trinity GBPRS_DEV_005844266_00281.jpg" with no problem at all, and they are both considerably longer names.

I left FH to think about its behaviour overnight and tried again this morning, with the same result. I then updated FH to 7.0.14 and tried again, with no change. Any suggestions?

Is the path for each of those files the same, as it's the overall path length that matters, not the file name length.

Sorry yes, I should have said that. The path is identical, all files are in the same folder.

Could it be you already have the file in your media?

Also it strikes me that the part of the file name beginning with GBPRS etc, may be the name of the file actually downloaded from whatever website you got it from. To my mind, saving this detail may be a waste of your time, as it doesn’t allow for the fact that the website may change their filing system in the future, so making this information useless.

Might be worth reconsidering your file naming convention, especially as you have already downloaded the file, with little likelihood you’ll do it again - just a thought.

No, FH always alerts you to that possibility by telling you it will save it as FileName(2). These were images freshly downloaded from FindMyPast. My routine is to find the record, download the image to a holding folder in Dropbox, immediately enter the data and attach the image. All images are copied to the FH project, and the originals later transferred to a permanent home.

Sometimes a file won't copy or move if the operating system thinks it is in use (whether it actually is or not). I've found this can happen if my cloud backup service is currently copying the file. Also, sometimes the file is incompletely downloaded (again, whether it actually is or not) and although it appears fine will not move or copy. I would suggest trying to move or copy the file yourself using File Explorer or similar and see what results you get. If it fails to move or copy, redownload a different copy. If it does move, it would appear to be an FH problem.

Is the problem with just that specific file?
Do other files with longer or shorter names get copied OK?
(I know you said they were OK yesterday but are other files OK today?)

Further experimentation suggests that it is indeed a file path length issue.

Death MORRISH Susan Western Times 21 August 1931.jpg will not download.

Death MORRISH Susan Western Times 21 Aug 1931.jpg will download. Very considerably shorter than
Burial MOUNTJOY Emmanuel 1756 Exeter Holy Trinity GBPRS_DEV_005844266_00281.jpg which downloaded just fine the day before.

Absolutely nothing in the setup was changed by me in the interim. So is this a Microsoft thing or a FH thing?

Have you upgraded FH between Burial MOUNTJOY Emmanuel 1756 Exeter Holy Trinity GBPRS_DEV_005844266_00281.jpg and Death MORRISH Susan Western Times 21 August 1931.jpg? What version are you running?

What is the full path and filename of where you are downloading FROM? Maybe that is too long!

Is that FROM path different to the Burial MOUNTJOY Emmanuel 1756.... download?

You said earlier that all Media is saved into the same FH Media folder with no subfolders involved.
So the full TO path is always the same.

Tatewise, the full path/file name of all the quoted examples is identical. They all come from the same Dropbox folder and are copied into the FH Media folder, no sub folders. It has to be a path length issue that somehow arose overnight; I had made no changes.

ColeValleyGirl, I upgraded to 7.0.14 after the issue arose, but both the examples you quote were tried under the upgraded version.

Interestingly, when I checked the internet for any reported problems, I found that the latest Anniversary Update to Windows 10 abolishes the maximum path limit completely. I don't have that Update, and I suspect my computer is probably too old for it (it's not suitable for upgrade to Windows 11) so I think a new PC is in my near future. I'll get cracking on backing up everything, but in the meantime I still have this very annoying problem.

Gowermick, you are right in thinking that the 'code numbers' at the end of the name indicate the source. I've always kept them just as an indication of where I found the image, rather than as a pointer to the exact location. I use generic source templates and don't record repositories etc so that is the only indication I have that an image came from FindMyPast rather than Ancestry for example.

Just FYI, 7.0.15 came out yesterday to fix a bug in reports introduced in 7.0.14 -- unlikely to help your error though.

Sorry, Maureen but I think you are misreading the maximum path length reports.
The Anniversary Update to Windows 10 was released in August 2016.
The relaxation of Path Length requires a Windows Registry change. It is not automatic.
Also, 32-bit applications like FH usually need to be modified to use the longer paths.

Thank you for clarifying the issue Mike. I try to be careful to check the dates of reports I read, but obviously slipped up there. I did take on board that a registry change was involved, but I forgot FH was 32-bit. Anyway, a brand new Windows 11 PC is on the way, and I shall take my time setting it up and simplifying my record keeping so as to avoid this situation in the future.