File Relation questions: What is the Master Folder and Specified Folder issues.

[Damit]

I am digging into file relations.  I had hoped to leave this for later, as it seems quite complicated, but realizing I had Stacks, Versions & Buddy Files all over my system, I feel like I have to figure this out before I find myself doing a lot of extra work.

First, I think this feature is amazing. It is just what I need as I keep untouched originals in a separate drive and while I do not want to alter them, I do want to move them to the proper folder in the Originals (Ori) drive, named O:, if moved in my Pictures (Pics) drive, which is the drive letter N:.

I have read all sections pertaining to the topic at least thrice and again while writing this post. My head is slowly starting to understand what I need to do. I am sure I will have other questions, but right now I am trying to understand one simple concept that I have to sort on before progressing. I have placed the questions I need answered in bold letters for the sake of clarity and brevity.

In the instructions the "Master Folder" is referenced but not really defined. I did a search and could not find one. What is the Master Folder?  I have several folders in my Pics Drive, how do I know which is the Master?  How is it designated? In Truth, the files in O: are the Masters, but in practice, the files in N: are the Masters, because that is where I do all, if not most of the work.

I guess I want N:, which contains all sub-folders that I will work on, as my Master. Everything should work perfectly as set up that way, as long as I instruct IMatch to check sub-folders for buddies and versions. The problem is that N also contains folders with photos that I have not yet included in my database.  I don't know if that is a problem or if IMatch just ignores the folders not in the database. I also don't know how I would designate N as the master folder.

The other thing I would have to do is O: as specified folder to lock for "Versions" of the files in N:. The folder structure is exactly the same in both drives, though some files have not been moved because, well, I did not have IMatch in my life until now and it is hard to be disciplined when moving files, especially if one is not doing it actively on at least a weekly basis. So some files will not be moved or found but I can live with that. The question is, do I have to include O: in my database to use this feature? It will add another 10 TB of photos to the database, which I assume will slow it down, but if I have to I guess I must? I would only want IMatch to move and/or rename the file in O:.  I would not want to alter the actual folder or its metadata at all.

Another question I have is if the folder structure is considered when identifying (indexing) the files. So if I have a img1668 in folder 2022-12-02 and also a img1668 in 2022-10-31 that they will be recognized as separate and not buddy files.  I assume not, as I do not see how this would work otherwise, but I just want to confirm.

Hopefully after I have this answered I can run some tests.

[Mario]

What is the Master Folder?

The folder containing the master file(s).

The problem is that N also contains folders with photos that I have not yet included in my database.  ...

The other thing I would have to do is O: as specified folder to lock for "Versions" of the files in N:.

IMatch looks for masters and versions among all files indexed by the database.
it looks for buddy files also among files not in the database. Many buddy files are intentionally not indexed by IMatch (application configuration files etc.).

The standard folder hierarchies used are:

A) master and versions in the same folder, or
B) versions in a sub-folder of the master folder

This makes setting up file relations very easy - because it's basically the defaults.
If you use a different folder hierarchy or you even split your masters across multiple disks, you need to learn about folder patterns and make some experiments to find a solution that works for you. This goes a long way, but not everything is doable, not even for IMatch. Simple is best when it comes to relations.

Tip: The Version panel shows all versions detected as soon as you do a <F4>,<R> on your test folder (to refresh relations based on your latest changes).

Note: Propagation of metadata happens when the master is written back.

[Damit]

OK, now with that piece of information this quote makes more sense.

"Having the same file extension for master and versions (e.g. some JPEG files are masters while others are versions of these masters) will cause problems because there is no way to tell by looking at a folder whether a file is a version or a master. This all then depends on which folder is processed first, and it cannot be guaranteed that the folder containing the versions will be processed after the folder containing the masters (e.g. when IMatch reacts on file system notifications about modified files and folders). Always use different file formats for masters and versions, or at least use a naming schemata which allows to tell whether a file is a master or a version - e.g. by adding a suffix to the version name: file001.jpg (master) file001_web.jpg (version)." (https://www.photools.com/help/imatch/rel_config.htm#a_match?dl=h-19)

So in order to make all the files in O: versions, I would have to add something to their name, like "o" for example? I also have some files that I added e and fe (edited & Final Edit) to the end of some files, so there seems to be some planning in my future to get this accomplished.

Have you ever considered allowing users to designate which are the master folders? It seems like a logical step that would solve a lot of problems, at least in my case, and I can imagine for many others, but what do I know? I fully recognize that there may be reasons why you have not.

Before I get ahead of myself, and do all this work, I just want to make sure that this will function as I envision it. Lets say I have the condition stated above, where everything is in the same folder structure in N: and O:, and I have placed a indicator, be it an "o" or something at the end of the file name to indicate that it is a version.  I test and make sure the versioning is working.

If I move a file in N: from folder N:\Test1 to N:\Test2 will IMatch move the version found in O:\Test1 to O:Test2, or will it move both files to N:\Test2?

Also please let me know if the folder structure is considered when identifying (indexing) the files. So if I have a img1668 in folder 2022-12-02 and also a img1668 in 2022-10-31 that they will be recognized as separate and not buddy files.  I assume they would be seen as separate and not buddies, as I do not see how this would work otherwise, but I just want to confirm.

[Mario]

Have you ever considered allowing users to designate which are the master folders?

Never. This also never came up and if you really, really, must do something like this (not recommended) you can do it via the variables features available for file relations.

If I move a file in N: from folder N:\Test1 to N:\Test2 will IMatch move the version

IMatch will move/copy/rename buddy files (not versions). If you want to do this, make sure you also create a buddy file rule. Versions and buddy files are separate.

Keep in mind that your folder structure seem to be very complex and your naming schema is not consistent. You may run into situations where IMatch may not be able to detect versions or buddy files or being unable to move/copy/rename due to the way you structure your file system.

So if I have a img1668 in folder 2022-12-02 and also a img1668 in 2022-10-31 that they will be recognized as separate and not buddy files

Each of the folders will be analyzed separately. First IMatch looks for masters, then, using these masters, it looks for versions in the folders specified in your file relation rule. And only in these folders.

Having masters or versions with the same in different folders does not do any harm, unless you somehow make IMatch search for versions in all these folders. It's important to be restrictive regarding the folders in which IMatch must search for versions. Don't let it search entire disks or folder hierarchies, because that's slow and prone to errors.

Having duplicate file names is not a problem per-se, but using unique file names using some sort of global id or date code or something is preferable. Especially when you work across platforms or with clients. The Renamer in IMatch makes this easy to do. Consider it.

As I said above, keeping things simple is the recipe for success with managing files, versions and buddy files. I cannot test every combination of stuff users come up with, and I cannot support every custom-made storage schema that only one or a few users will ever come up with. 80% of the work go into 20% of the use-cases, without accounting for even more rare "special" use-cases some users come up with...

[Damit]

Thank you so much for your response and advice. I have been thinking about this on and off this weekend. IMatch is making me rethink a lot of what I did in the past and is forcing me to be better organized.  
I really wish I had it in the past. Unfortunately I did not discover it until recently.

I will look into the variable features for file relations (looks a bit complex initially) and the Renamer and consider your advice. It seems that designating Master folders is not the way to go. I have to really consider what I am doing and what you are advising. It seems I have to come up with a file naming system or at least a strict way of naming versions and sets of files.

KISS is a great principle.  I am trying to simplify things.

As far as Buddy Files, I do realize they are separate. I was actually talking about buddy files, which is what my originals could be considered and since I will not be touching metadata of any sort in my originals, I think I will just treat them as buddies and then I might not have to rename a bunch of files (over 248,000) adding some sort of suffix. I don't know, maybe I still do. One problem I can foresee is that my "Masters" will have an e or fe or (FE) at the end of them (You were right, I was inconsistent). Hopefully once I figure out a good file naming scheme this will simplify things.

One issue I have with the catchall file relation expressions currently supplied with IMatch is that windows adds a (1), (2) and so to the end of the file name if you move a file to a folder where another file with the same name exists. Most of the time this is because you are adding another copy of the same picture (usually without knowing it), but sometimes it may be a completely different picture, usually taken by another camera, that just so happens to have the same file name.  I would NOT want IMatch to group these as versions.  It seems the catchall phrase has its caveats.

Of course, if one is disciplined with file naming one can set up more specific expressions for matching and avoid these problems.

I knew I would have to consider a lot of stuff before I actually started getting to actually tagging my photos but I never imagined how much.  The preliminary work is tedious but necessary in order to avoid, as much as possible, creating more of a mess!

[Mario]

One problem I can foresee is that my "Masters" will have an e or fe or (FE) at the end of them (You were right, I was inconsistent). Hopefully once I figure out a good file naming scheme this will simplify things.

This is not a problem. That's why IMatch is using the 'dreaded' regular expressions for this.
These are usually as simple as "masters": \.raw$  (all files ending with .raw).
But they can be more complex when needed, e.g. while dealing with inconsistent file names like masters sometimes ending with e or fe (in regexp this is written as [e|fe]).

Tip: Use the Test button in the File Relations dialog to test out regular expressions, or one of the many web sites for that purpose. You can also ask in the community for assistance.

Expect to spend some time learning when you want to do more complex and out-of-the-ordinary things.

(...) I really wish I had it in the past. Unfortunately I did not discover it until recently.

That's the power of marketing. Adobe alone has a annual advertisement budget of about 150 million US$...
I cannot compete with the ad budgets of Adobe, ACDSee and the likes. Their marketing and SEO departments are very effective.

For example, I could use Google ads. But even Google admits that with a budget of less than 5,000$ per month (!) you don't really get any positive results. Waaaay to expensive. And my bids would have to compete against competition like Adobe, Extensis, FotoWare or ACDSee for "DAM keywords" ...

Help to spread the word. If you are satisfied with IMatch, let others know about it, e.g. in photography forums, Facebook, ...
 

KISS is a great principle.  I am trying to simplify things.

Yup. Keeping folder layouts and file names simple and consistent not only helps with your DAM but also in simpler applications like Windows Explorer. IMatch does not require or enforce a specific workflow or folder hierarchy. It manages your files where they are and is very flexible.

Often. when people switch to a true DAM like IMatch, they spend some time re-organizing things, checking for and fixing broken metadata, ensure that their metadata is consistent, maybe switch to a more consistent file naming schema and folder organization.

Simple and consistent should be the goal. What that implies varies from user to user.

IMatch has many tools to support you with that and cleaning up things will not only make IMatch's job easier (and yours), but will also be helpful for other applications and services.

[thrinn]

It seems I have to come up with a file naming system or at least a strict way of naming versions and sets of files.

It pays off to spend some time thinking about a consistent file naming scheme. Just to give you some ideas, there is a very old but still valid thread. IMatch does not force a special way of naming on you, but consistency will make your life much easier. Some points to think about:

• Which information do you want to have in the file names? E.g. including the date the picture was taken somewhere in the name is not uncommon.
• Do you want to include some kind of "counter" to make the names unique? I like to have a counter starting at 1 per day, for example. Others (like sinus) include a "global file counter".
• From my experience, having master and versions starting with the same part of the filename simplifies the definition of file relation rules.

As you have apparently master and versions on different drives, be careful when renaming folders: A buddy file relation can take care of renaming the buddy file if the master is renamed, but I am not so sure that this will also work for folder names.
One tip: Before you start renaming big bunches of files, consider if you want to store the "original filename" in some metadata tag. I do this by using a Metadata Template which will automatically run when indexing new files. This way, if something goes wrong, it is quite easy to rename files back to their "original name".

[Damit]

Thank you for the tips, Thorsten!!  I really need all the help I can get.  I have spent the last hours trying to figure out regular expressions again!

[Mario]

Tip: IMatch by default stores the original file name in XMP::xmpMM\PreservedFileName\PreservedFileName when you rename a file for the first time in IMatch (unless that tag was already filled by another application).

IMatch renames buddy files along with the master and can even create sub-folders dynamically as needed.
But renaming folders containing masters will not trigger buddy files, because buddy files work on a file and not folder level. Since renaming a folder containing a master does not rename the master file, buddy file management is not triggered.
There are things too complex even for IMatch.

[Damit]

Tip: IMatch by default stores the original file name in XMP::xmpMM\PreservedFileName\PreservedFileName when you rename a file for the first time in IMatch (unless that tag was already filled by another application).

That is awesome!!! Man, its like you have been thinking about metadata for over 20 years!
THis is why I am trying to be disciplined and doing all my renaming, moving etc in IMatch.

IMatch renames buddy files along with the master and can even create sub-folders dynamically as needed.
But renaming folders containing masters will not trigger buddy files, because buddy files work on a file and not folder level. Since renaming a folder containing a master does not rename the master file, buddy file management is not triggered.
There are things too complex even for IMatch.

Come on Mario, don't be lame, you can do it! I believe in you! LOL!
I can understand why this would not be worth trying to conquer.  I think I am just going to leave my originals alone and out of IMatch and if, for some reason, I need the original I can do a term or similar image search with one of the products I bought for this.  They are really only there in case of an emergency.

[Damit]

I am thinking of using a "." Before any modifiers for versions. This way I can put anything after the filename as a note to what I have done.

EX: img001.final edit.tif, img001.copy.tif, imag001.edit1.tif

I was going to use this for linking the files.

Master Expression:
 \.(tif)$
Link Expression
^(_*{name})\.[+\-_]*[0-9|a-z]*\.(jpg|jpeg|dng|tif|tiff|arw\.dxo|arw\.dop|on1)$

This will match any filename that has a "." In front of the modifier
Img001.tif will match img001.anything.tif

Do you see any problems/caveats in doing this? The only problem I have had is if I want to have spaces in the modifier, like img001.mother of all edits.tif

I am not sure how to write it so to allow for spaces.

But other than that, is there any issue you can forsee in using a "." for this purpose?

P.S. I WILL spread the word.  I already have, but I want to be a little more versed in the program so I can give an adequate review.  I am taking notes as I go.

[Mario]

The regular expressions used for file relations can deal easily with version/buddy file names that have more characters than the master file name, e.g. an added number of suffix/prefix.

When the name of the master could be ABC.RAW or ABCe.RAW or ABCfe.RAW, things become more difficult.

Consider a version regexp like the default expression used for new rules:

^(_*{name})[+\-_]*[0-9|a-z]*\.(jpg|jpeg|dng)$

This allows version file names like ABC.jpg or ABC+1.jpg or AB_C121214.dng when the master file name is ABC.RAW
The {name} in the regexp is replaced by the name of the master file (ABC) before the regular expression is processed. So, for a master named ABC.RAW, the expression becomes

^(_*ABC)[+\-_]*[0-9|a-z]*\.(jpg|jpeg|dng)$

and it will just work. But what if the master is sometimes ABCe or ABCef ?

^(_*ABCe)[+\-_]*[0-9|a-z]*\.(jpg|jpeg|dng)$
^(_*ABCef)[+\-_]*[0-9|a-z]*\.(jpg|jpeg|dng)$

and this will not work, unless the version also has the e or ef in the file name.

That is why I've added the replacement expression to the design. If allows you to strip the e or ef from the master file name before the regular expression is processed. The typical use case are RAW file names starting with an _ while the versions don't start with a _. But you should be able to make this work with your e or ef suffixes too.

See Replacement Expression (Advanced Topic) in the IMatch help for some samples.

That being said, using different suffixes or prefixes for master file name is not a good idea. Settle to one naming convention, rename all masters that don't match whatever you decide on before you let IMatch search for relations. This will make matching masters and versions much easier.

Tip: From the top of my head (not tried) you can use the File Window search bar with this expression

ef\.[a-z]*$

to find all files with ef in front of the extension. To search for a specific extension only, use something like

ef\.raw$

Same works for files having only an e in front of the extension  e\.raw$

This should allow you to find masters with file names containing one of the random embellishments.

[Mario]

I am thinking of using a "." Be

Don't use multiple . in a file name. While IMatch is fine with that, many other applications may run into problems, especially when you switch between platforms. Use a safe character like an _ or -

[Damit]

Thank you for all the advice. I will try to digest this properly before responding.

I am glad I asked about using "."  While I don't like the idea of using "-" or "_" only because they seem to already housed in some file names. I know some copy programs use a "-" for copies (img001-1.tif or img002-2.tif for copies for files imported to a folder with a file with the same name.

That is the reason I am reluctant to use the catchall expression provided by IMatch because, as aforementioned, IMatch will believe img001-2.tiff or img001-1.tif are versions of img001.tif even though that may not be the case.

I guess I can use the underscore "_"

Any other characters that are deemed safe?

[Mario]

IMatch will believe img001-2.tiff or img001-1.tif are versions of img001.tif even though that may not be the case.

Using the same extensions for masters and versions in the same folder is not a good idea.

You could also just leave out the - as a potential character for the version file name: [+\-_]* becomes [+\_]* in that case.
Since versions then cannot contain -, they will not be detected.
Unless you sometimes have versions which contain -

In that case, my comments about consistent file naming apply.

IMatch can do a log, but it cannot do everything.

[sinus]

It seems I have to come up with a file naming system or at least a strict way of naming versions and sets of files.

It pays off to spend some time thinking about a consistent file naming scheme. Just to give you some ideas, there is a very old but still valid thread. IMatch does not force a special way of naming on you, but consistency will make your life much easier. Some points to think about:

• Which information do you want to have in the file names? E.g. including the date the picture was taken somewhere in the name is not uncommon.
• Do you want to include some kind of "counter" to make the names unique? I like to have a counter starting at 1 per day, for example. Others (like sinus) include a "global file counter".....

Indeed an old thread, respect, that you found it, Thorsten. 
Yep, I use a kind of "global file counter".
Means, each file becomes a uniqe file-number. I have startet (I guess, 2001) with 000001 and now I am at 443158.
I thought, I will not have over 1 Million files, and this seems to be true. 
But I do not care, if I delete some files, hence these numbers are not more in the DB. 

My current, last filename ist this:

20221208-1427-443158-s-coo-lastwagenleute_a

I am happy with my naming-system and I have no problems to find files.

But of course, there are hundrets of systems out there, and maybe dozens of good ones.

[Damit]

Man, that sent me down a RegEx rabbit hole! More on that later...

In my file system, .tiff or .tif are usually the master, unless there is a .psd. Sometimes I just have jpegs, and another jpeg could be a slave, as when I make multiple edits of an original jpeg. I know Mario has cautioned against using files with the same extensions for masters and versions in the same folder, but if I can get away with it I would prefer to keep multiple edits of a master file right next to them for browsing with other applications.

This brings me to ask:Do the relation definitions have a hierarchy? I think I read somewhere that they do not, but I cannot find it. I am not sure it really matters.  

I am just wondering how I can set things up so if there are .psd and .tiff that the .psd would be the master, but if there are .tiffs and no .psd that the .tiff would be the master? Similarly, if there are no .tiffs or .psds that the Master jpeg would be the Master (img01.jpeg (Master) img01-2.jpeg (version)).

Could I do this by just creating Version Relation Definition for .psd where it is the Master and all other files defined as versions, and another Version Relation Definition for .tiffs where it is the Master and all other files, except .psd, are versions, and the same for jpegs, with all files except .tiff & .psd as versions? The more I think about it, I do not see why not, but I am just wondering if, for example, IMatch may assign versions based on .tiff Version File Relation Definitions after it defined the versions for .psd files, and, as a result, the .psd ceases to be the Master and the files that should be related as versions to it, are not longer defined as such. They same could happen with the jpegs. If there was a hierarchy, say in the order they are listed in the Relation Definitions Box in the File Relations section of Preferences, it could deal with such issues, but I am not sure if such a hierarchical function exists. 

Anyhow, back to my RegEx exercise, in order to deal with .tiff and .tif files I set up the following:
Master Expression:
\.(tif|tiff)$
Link Expression:
(_*{name})((_[+|,|!|;|\-|_\(|\)|\{|\}|\[|\]|[0-9|a-z]*\.(tif|tiff))|([+|,|!|;|\-|_\(|\)|\{|\}|\[|\]|[0-9|a-z]*\.(jpg|jpeg|dng|arw\.dxo|arw\.dop|on1)))$

I think this will tell IMatch that for another .tiff or .tif file to be considered a Version a Master .tiff or .tif file, it must have the same file name, preceded or not by any number of underscores, and succeeded by an underscore followed by zero or any other character allowed in filenames.
And also for a .jpg, .jpeg, .dng, .arw.dxo, .arw.dop, or .on1 file to be considered a Version of a Master tiff or .tif file, it must have the same file name, preceded or not by any number of underscores, and succeeded by no characters, or any other character.

I know there is probably a cleaner way to write it, but I could not find an appropriate shorthand character class so it is the best I can do. Anyone see any problems with this?

Using the same extensions for masters and versions in the same folder is not a good idea.

If you are anyone else could be so kind as to explain why or point me to a article on the matter?  I believe with the proper rule definitions this should not cause a problem but I often overlook that which I can not realize!

Lastly, is there a place where I can reset which file extensions IMatch will look for when performing File Relations.  There was an option when I first set up my database asking which files are used and I see they are set up in the catchall phrases.  I then read that it would be best to trim this list as much as possible and omit file types not currently residing in your system, so I want to take some out (like arw.dxo).  I know I can do this manually, but I am wondering if there is a place I can bring up that option check box and uncheck so file types.

[Mario]

This brings me to ask:Do the relation definitions have a hierarchy? I think I read somewhere that they do not, but I cannot find it. I am not sure it really matters.  

It's explained in the help. The definitions are processed from top to bottom.

I am just wondering how I can set things up so if there are .psd and .tiff that the .psd would be the master, but if there are .tiffs and no .psd that the .tiff would be the master?

No.

Could I do this by just creating Version Relation Definition for .psd where it is the Master and all other files defined as versions, and another Version Relation Definition for .tiffs where it is the Master and all other files, except .psd, are versions, and the same for jpegs, with all files except .tiff & .psd as versions? T

Theoretically. But chaining versions that way is a potential recipe for disaster. (PSD is a mater of the TIFF which is a master of whatever, and all mixed in one folder, ...) I remind you of the KISS principle again.

You can test your regular expressions in the Test dialog included in the File Relations dialog box.

If you are anyone else could be so kind as to explain why or point me to a article on the matter?  I believe with the proper rule definitions this should not cause a problem but I often overlook that which I can not realize!

Experience. If you can guarantee with your file naming conventions and File relations that no version will ever be accidentally detected as a master, go ahead.

Lastly, is there a place where I can reset which file extensions IMatch will look for when performing File Relations.  

Edit > Preferences > File Relations.
The initial onboarding dialog is only available when you setup a new database. There is usually no need to run it again, since the default relations are in the database - unless you delete or modify them. If you really need this for some reason, create a new database and to a copy & paste in Edit > Preferences > File Relations afterwards.

[Damit]

I am trying to use this link expression:

([+|,|!|;|\-|_\(|\)|\{|\}|\[|\]|[0-9|a-z]*{name})(([+|,|!|;|\-|_\(|\)|\{|\}|\[|\]|[0-9|a-z]*\.(jpg|jpeg|dng|arw\.dxo|arw\.dop|on1)))$

which works well unless there is a space after the file name.  For some reason that gets rejected, which is weird because I am using the same components prior to the file name as I am using after it, so I do not understand why a space after the name is rejecting the match.

For example:
Master: IMG_4535.jpg
Version: tt.fdgsg IMG_4535-1a(edited).jpg   will match but
Version: tt.fdgsgIMG_4535-1 a(edited).jpg   will not.

Any suggestion on how to get the file relation to accept the space after the file name in a match?

[sinus]

If it works well for you, except for files with a space after the file name, well, I personally would simply delete all spaces after filenames or change the space into a - or _ or z or whatever.

My personal believe is, that I would never use spaces in a filename, like I would not use umlauts (äöüé ...) in my filenames, it brought me only problems over problems, but mostly not in IMatch, but with other programs, internet-provider and so on, ah, yes, and problems exchanging file with graphic designers, they mostly use Apple. One of my client (a big company) has restrictions, how to give filenames, only lower case letters and numbers, and the - and _

In your regex-question I can not help, unfortunately, I have almost no experience there.

[Mario]

It seems your massively complicated regexp does not allow for a space after the file name?
You allow for + , and a lot more but I don't see blank. I could not look for too long, because my eyes started watering...

[Damit]

Thanks Sinus!

You make good points and I have also determined, from comments in his posts, that Mario would agree with you.  I have read about having spaces in a file name causes problems, but I have never, in my 35 years of using computers ever experienced them. I guess I have been lucky and I do not say that sarcastically.

The problem is that since this has not been a problem, my files are replete with spaces, so it would be laborious to do what you suggests, even though that, in itself, does not make it a viable solution. I may have to consider not using spaces.

Luckily I am not doing this professionally, but who knows.

It seems your massively complicated regexp does not allow for a space after the file name?
I don't see a case for this. But I could not look for too long, my eyes started watering...

I am sorry.  I try the best I can. I am no expert, obviously, at regex, but I do appreciate you taking a look.  I cannot figure out why the regexp does not allow the space after.  Perhaps someone else can.

[Mario]

...{name})(([+|,|!|;|\-|_\(|\)|\{|\}|\[|\]|[0-9|a-z]* 

There is no space in this.

[Damit]

...{name})(([+|,|!|;|\-|_\(|\)|\{|\}|\[|\]|[0-9|a-z]*

There is no space in this.

I tried addind a "| " or "|/s" but that did not work. There is also no space in the
([+|,|!|;|\-|_\(|\)|\{|\}|\[|\]|[0-9|a-z]*
but it works for some reason.

Basically I am trying to say ANY ALLOWABLE CHARACTER{name}ANY ALLOWABLE CHARACTER.photo extensions used in my system. Like you said, I probably have over-complicated the issue.  Maybe just *{name}* will work.  I am experimenting.

[Mario]

Any character would just be .*
Since you don't allow blanks, the match won't work.

Using the simple RegExp tester app I provide in IMatch, it is easy to figure out.
The yellow box is a blank. If you remove it, there is no match because there is a blank at the end of the file name "bannana .jpg".

 

Allowing for the blank fixes that.

[Damit]

Thank you, once again, Mario!!! This is very much appreciated!
 
I was putting the space after the closed bracket (0-9|[A-Z] ) . I was using the tester in the file relations widow, but I realize now I could have also used the app. It might have made things a bit easier. Your program is so extensive and varied (another thing that makes IMatch so unique) it is hard to remember all the tools. Maybe one day I will get there. Hell, even you forget about some features! But I do appreciate you reminding me.

[thrinn]

Also keep in mind that you can open the RegExp Tester app (in fact, every app) "detached" in a separate browser window to try things out. This way, even if you have the File Relations preference window open (which blocks the user interface) you can still use the app for testing.

[Mario]

Thank you, once again, Mario!!! This is very much appreciated!
 
 I was using the tester in the file relations widow, but I realize now I could have also used the app.

Same thing. Both use the same regexp processor.