desktop.ini

This is something that came to my attention only recently and from searches it's clear it was not an issue previously. What caused it to start I don't know. I'm using Windows 10.

This can mess up your files everywhere; it's not specific to MRIN Filing but can certainly affect it.

It's a text file called 'desktop.ini'.

How it comes about is when you rename a folder and move its location it will create a desktop.ini to hold onto the old name. In the process it will actually refuse to register the new name. The file will look something like this where 51489 DHT-MHB is the folder name:

[.ShellClassInfo]
LocalizedResourceName=@51489 DHT-MHB,0

You can see how this would be a problem for your MRIN Filing. If you want to know if this has already affected your system, open the folder where you keep your MRIN Sources and do a search for desktop.ini. Hopefully you won't have any. If you do, you'll have to go to each folder and adjust accordingly.

What I've done is turn on the options at the top of Windows Explorer and tick, "Show Hidden Items" like this:

If a desktop.ini is suddenly created it will show itself next to the folder I've renamed. All it takes to get things back on track is to delete it.

If you're looking for a more satisfying way of fixing this, here's a simple video with the commands you'll need below the video:

How to Stop Desktop.ini File from Opening Automatically on Windows 11/10 Startup [Tutorial]
https://www.youtube.com/watch?v=RyzhgovPkJY

Searching By Name

Of all the things that are important in this filing system, the MRINs and the metadata are at the top of the list; file-names are at the bottom.

If you're using one of the surname systems without metadata, you'll be searching for names that are in your file-names assuming that you can squash a whole bunch of people into a file-name.

If you're using the MRIN Filing System+, you're probably looking for people by searching keywords/tags. I never search by file-names because I know it won't give me good results. Why? Because all the names attached to a document or photo are not in the file-name.

You can use both systems but you have to use at least one of them to find your files.

Obviously, I'm partial to the metadata approach because it's way less prone to errors and omissions.

The default approach for file-names as described in the book is:
MRIN-Date (1920, 1920s, 1920ca or xxxx) Record type, Name (First name Middle initial(s) Surname)
Maiden names for females
For married couples: (husband's) Surname-(wife's) Surname
For photos, leave out Record Type
Group photos: use the MRIN and name of the oldest person in the group:
(oldest person) & family
& sons
& daughters
& children
& cousin
& siblings
or whatever the case may be.

Keywords/tags will take care of the rest. 

When I very first started out, I was so adverse to long file-names I put names like 0027-1903ca-01 (2) on photos. I've cleaned them up for the sake of clarity but in this system it doesn't actually matter because the MRINs and keywords contain anything you're looking for in that way.

Searching for 'Beeken', I get everything with Beeken anywhere if the Folder path contains the word Beeken. Over 12,000 files. Windows doesn't discriminate unless you tell it to.

If I search for 'tags: Beeken' I get 517 results from having added keyword (tag) metadata to my files. 

If I search for 'name: Beeken' I get less results because not all my file-names contain Beeken. There's all kinds of obvious reasons for that. For instance a Beeken female is in a census record listed under her husband's name. Or a Beeken child is in a census record under his uncle's name. Or he's in a group photo that's filed under the MRIN folder of the oldest person in the photo who's not a Beeken. He's in the keywords (tags) but not the file-name.  

There are other things that can get in your way. For instance searching for 'Harris' will also bring up anyone called Harrison. If the search term is put into double-quotes, as "Harris", it will just look for Harris as a whole word.

My marriage records are named as MRIN-date marriage, Surname-Surname, eg. 0345-1939 marriage, Bailey-Beeken. So, if I'm looking for the husband "Marion W Bailey" specifically I won't find this in the search results for 'name: Beeken'. A keyword/tag search will find it though.

There's a nifty box in Windows under the Search tab that shows more options for narrowing down searches. For instance I wouldn't want to search just 'west' when I'm looking for my West surname because I would get everything else that has West in it; West Virginia for example. So I search 'tags: WEST' to narrow it down.

If I want to go the other way and search for WEST that's not a surname I would search West minus West as a keyword i.e. WEST - tags: WEST 

WEST (1,568 results)
tags: WEST (518 results)
WEST - tags: WEST (1,050 results)

The point of all this is that you can only find what's in your files. Consistency is key. Make up your own 'rules' and stick with them so you know what you can do with searches and what you can't. This system was designed to cover a range of options.

Direct-lines vs. Top-of-the-line

If I was doing this only for myself I would nest the direct-line folders down into top-of-the-line ancestors. (pp. 72 & 92 of the book). But I've been here before.

I once wrote part of my family history as cliff-hanger installments and sent it to two sisters and a niece. I started at the 6th generation because one set of 4th great-grandparents met on the banks of the Susquehanna and immediately fell in love (as the story goes) and migrated to Ohio. It was a very romantic and obvious place to start, in my opinion. And then the story went backwards into the American Revolution and forward to the present.

I got NO response until I sent a picture of the family homestead built in the 1830's overlaid with photos of the first generation to grow up there. Yay, photos!

And later, when I got close enough to the present to send a photo of a great-aunt who looks like one of my sisters, there was an "Oh, I get it!" moment.

I have a list of people who are going to inherit my family history work, whether they want it or not. I've already set up backup drives for each of them that are updated regularly in case I drop over suddenly. Some of them may never get past the MRIN vault and that's OK.

My vault is looking quite busy with 116 direct-line folders.

Now that I think of it, another idea would be to go ahead and nest all the folders down and leave a README text file with a list of all the MRINs for the direct-lines and a simple explanation of how to search for them. There's a free program called Directory List & Print that can do this. 

But I'm still not going to do it that way. There are enough explanations that come with the filing system as a whole and how to install and set up Legacy. I want to give them just one thing that's got a big START HERE button that goes directly into our parents' folder and brings them into the heart of it. They don't have to think; they just have to go there and then there's some chance it will pull them into the rest of it.

It's one of those things where there's no right answer. Consider who you're sharing your family history with when you're gone and can't be around to explain it anymore.

LTools

LTools for Legacy was discontinued some time ago and the website shut down. The latest installer can still be downloaded from my Dropbox at http://bit.ly/44m4VQQ

The only purpose of LTools in this filing system is to add each MRIN to the related User ID fields. This is quite important for navigation and can be done manually instead.

ALTHOUGH, there is an option in Legacy under Customize/Other/Custom User ID Numbers to "... create User ID Numbers by having the RIN or MRIN copied into the field..." which amounts to the same thing and will be much quicker for you. This does not work for MRINs in Legacy v.7.5 but may work in versions 8 or 9.

At least with v.9 of Legacy you can ask tech support to fix that feature if it still doesn't work. And that will be a good thing because LTools, I've been told, does not work with versions 8 or 9 of Legacy. 

LTools will still work with v.7.5 but needs to have an older version of .NET framework installed first. It will tell you which one when you try to install it. I couldn't get the exact number it asked for, 2.0.50727 from the .NET website. The closest I could get was version 2.09 and it didn't work.

BUT, it wasn't over yet. There are very simple-to-follow instructions at https://www.groovypost.com/howto/enable-net-framework-2-windows-8/ for enabling earlier versions of .NET on your Windows 8 or Windows 10 computer. I've put a copy of this page in the zip folder at Dropbox along with the LTools installer in case it disappears from the Internet.

Don't get impatient if it seems to stall. It will get there. Once that's done, LTools will install seamlessly.