Versions perpetually need to be written unless only their master a written.

[Damit]

I am testing a version I have set up for .cr2 files. The version is propagating XMP, all data with cropping disabled, and Don't copy XMP orientation.  No ther options are ticked. The version defination (not that I think it matters) is

^({name})(\(([^cC|rR|sS].*?)\.((jpg|jpeg|cr2|dng|png|tiff|tif))?|\.(jpg|jpeg|dng|png|tiff|tif))$

When I try to writeback to these files they would constantly reappear in the Files needing write-back collection.  I then thought about it and tried just writing to the master to see if the data would propagate and update the .jpegs and I was correct. The files no longer appear to need a write-back.

It seems that trying to write-back all the files, which included the .jpeg versions of the cr2 masters that also needed updating caused a cycle where perhaps the updated information was being erased in the jpegs, but I don't know how that would affect the .cr2s and stop them from being updated. Still, it worked, but I thought I should understand why and see if this is normal behavior.

[thrinn]

Is the regex in your post the Master Expression or the Link Expression? If it is the Link Expression, it appears that you also want to catch CR2 files as versions. Is this what you intend?
It would be helpful to have an actual sample filename of one of the files you see as master, and also of a corresponding version.

[Damit]

Thank you Thorsten,
This was the Version definition. Here is the Master definition:

Master expression: \.(cr2|cr3|crw)$

Yes, that is what I intended; in case I edited the cr2 file itself.  As you may see, the condition to match it requires an open parenthesis, which is what I use to indicate something is edited of has some difference. that is why I would want it as a version.  But you got me thinking.  Will I ever do this?  Probably not, but does it hurt to leave it in there in case I do?

Most of the files caught by this are in this form:
Master= IMG_5169-Trying this again.cr2
Posible Versions=
IMG_5169-Trying this again(c5X&_HFS).cr2
IMG_5169-Trying this again.jpeg
IMG_5169-Trying this again(c5X7,e02[+Sat]_MJS).jpeg

Still, I don't think any of this factors into what I have observed, but I could be wrong.

[Mario]

Do not make a file it's own master or version. The results are undefined.

[rolandgifford]

Do not make a file it's own master or version. The results are undefined.

Small alarm bells for me from this comment if I have understood correctly.

My camera is set to produce raw/jpg pairs. My wife's camera and our phones only produce jpgs.

These files go into a single folder. After culling I sometimes edit the raw file (or jpg if no raw file) and produce another jpg/afphoto pair which goes into a sub-folder of the master. Same base file name.

I have versioning/buddy rules which have the jpg as the master and looks for files with the same name in the current folder and the named sub-folder(always the same name) and looks for raw(several types), afphoto and and jpg files. I have the jpg as the master as that is the image I want to see in the file viewer and there is a filter to hide buddy files which allows me to do that.

I take the comment to mean that I can't have a jpg master and a jpg child (same name, different folder) in my versioning rule. I can't change to having a raw file as a master as there sometimes isn't one and I would need a jpg as master rule for that circumstance.

Have I misunderstood the comment? How do I define a rules with a jpg master and a jpg child?

[Mario]

You just must make sure that when IMatch travels the version chain starting from a master does not accidentally find the master.
Or that you don't create rules which make the same file sometimes a master and sometimes a version.

People sometimes use strange naming conventions and setup weird self-referential file relation rules. IMatch can do only so much to protect users from shooting themselves in their own foot.

Having versions in a sub-folder below the folder containing the master and letting the rule only search down in folders is very safe and easy to understand and verify.

If you keep masters and versions in the same folder, use a naming convention that makes it impossible to confuse a master with a version. Or be very precise when setting up the regular expressions which detect what's a master and what's a version. Else there might be trouble.

I cannot envision everything that users can do with folder layouts, file naming conversions, file relation rules and regular expressions. Impossible.

When a user has to setup a regular expression like ^({name})(\(([^cC|rR|sS].*?)\.((jpg|jpeg|cr2|dng|png|tiff|tif))?|\.(jpg|jpeg|dng|png|tiff|tif))$, chances are the naming convention used is too complex or the folder layout is not designed to deal with this etc. I keep regular expressions very simple for all my own use cases, for good reasons. Too complex usually means error prone and I don't want that. KISS is better.

You can use relation variables to gain additional insights in how your file relations work and if they really do what you think they do.

I'm not a regular expression expert (in fact, many users are better with regexp than I am) and sometimes users completely bamboozle me with file relation setups they have created. KISS is always better in my option.

[rolandgifford]

You just must make sure that when IMatch travels the version chain starting from a master does not accidentally find the master.
Or that you don't create rules which make the same file sometimes a master and sometimes a version.

I'm still confused

I have .jpg declared as a master and a link expression of:
^({name})\.(jpg|jpeg|dng|tif|tiff|arw|cr2|faf|raf|rw2|afphoto|dng|arw)$

which allows for a jpg to be a child of the master being looked at. I regularly have jpg files (in a sub-folder only) as a child. Raw files are always in the same folder as the master jpg.

I search down for a list of folders being the master folder and a single fixed name child folder off the master.

If IMatch specifically excludes the master being processed as an available child I'm OK. If it doesn't do that it will always find the master as a child. How do I change my link expression so that it only looks in the named sub-folder for jpg children but the master folder as well for child raw files?

[Mario]

Two relation rules, one for each case?
One that looks only in the master folder. The other which looks for versions only in the sub-folder?

Don't take my general comments to seriously. If you have validated your file relations and you're sure that it does not accidentally detects a master as a version, you're good.

[rolandgifford]

Two relation rules, one for each case?
One that looks only in the master folder. The other which looks for versions only in the sub-folder?

Would that have all children found by either rule? I hadn't considered having two versioning/buddy rules for the same file type, assuming that the second would replace the first rather than add to it.

Don't take my general comments to seriously. If you have validated your file relations and you're sure that it does not accidentally detects a master as a version, you're good.

How would I know? IMatch not showing the master as a child doesn't necessarily mean that relation doesn't exist

[Mario]

What is a child? You have masters and versions. IMatch looks for versions in the folders you make it search. If you mix masters and versions in the same folder, use naming conventions to allow IMatch to tell what is what. Not sure how I can help with that, this all depends on your file names, folder structure and the rules you set up.

How would I know? IMatch not showing the master as a child does

What does that mean? What is a child? A version?

Where would IMatch not show that?
When you select a master, it shows all versions in the Versions Panel. Is this not the case?
The variable I mention will list all versions. Is this not the case?
If your rule does not detect the master as a version, it will not be listed. What makes you doubt that?

[Damit]

Mario, the rule does not make a Master a version of itself.  I did extensive testing and IMG_899.cr2 will never be a version of IMG_899.cr2, unless your testing algorithym is malfunctioning.  Now will IMG_899(e2).cr2 or IMG_899(.cr2 or anything with a `(` after the {name} be a version of IMG_899.cr2? Yes, but how is that a problem, because they are NOT the same file?  And I was wrong when I said I would never do this.  I knew there was a reason I set up the rule that way, I had just been away from this project, and it slipped my mind. Maybe I want to make some changes to the RAW .cr2 file and save those RAW changes as an altered version of the .cr2. I would think that this a basic function and a reason why versions and masters were created. Maybe I am wrong, but I don't think my versioning rule creates a problem.

When Roland is saying child, I think he means a version.

[thrinn]

Thank you Thorsten,
This was the Version definition. Here is the Master definition:

Master expression: \.(cr2|cr3|crw)$

Yes, that is what I intended; in case I edited the cr2 file itself.  As you may see, the condition to match it requires an open parenthesis, which is what I use to indicate something is edited of has some difference. that is why I would want it as a version.  But you got me thinking.  Will I ever do this?  Probably not, but does it hurt to leave it in there in case I do?

Most of the files caught by this are in this form:
Master= IMG_5169-Trying this again.cr2
Posible Versions=
IMG_5169-Trying this again(c5X&_HFS).cr2
IMG_5169-Trying this again.jpeg
IMG_5169-Trying this again(c5X7,e02[+Sat]_MJS).jpeg

Still, I don't think any of this factors into what I have observed, but I could be wrong.

Now I am confused. None of the three files you describe as "possible versions" is detected as such.
The master expression is "any CR2/CR3/CRW" file:

Code Select Expand

\.(cr2|cr3|crw)$
The link expression is

Code Select Expand

^({name})(\(([^cC|rR|sS].*?)\.((jpg|jpeg|cr2|dng|png|tiff|tif))?|\.(jpg|jpeg|dng|png|tiff|tif))$
The first and third of you sample files are not detected as versions because they have letter "c" after the opening bracket. My understanding (also taking into account the discussion in one of your other posts) is that this is indeed what you want: To be catched by the link expression, the first character after the first opening bracket must not be one of the letters c,r,s.

The second file is also no version because the link expression requires a version to have an opening bracket after the original name.

But if none of the samples is a version, I don't see how propagation can come in to play.

[Damit]

Sorry, you are right, I don't know what I was thinking, and I wish I could correct it. Quite embarrassing!   The 1st and third example would indeed NOT match because of the `c`. Let me see if I can get this right this time. These would match the Master file name: IMG_5169-Trying this again.cr2

IMG_5169-Trying this again.tiff
IMG_5169-Trying this again.jpeg
IMG_5169-Trying this again(e01_HFS).cr2
IMG_5169-Trying this again(fe05_MMDF).cr2
IMG_5169-Trying this again(fe05_MMDF).tif
IMG_5169-Trying this again(e01_HFS).jpeg
IMG_5169-Trying this again(e01_HFS).png
IMG_5169-Trying this again(klj'sd;fkjf'a;djfpjspd).cr2
Pretty much anything that possesses the same initial characters as the original file name followed by an open parenthesis would match if it is a .jpeg, jpg, .cr2, .dng,. .png, .tiff or .tif.
Any file with the same exact file name and is a .jpeg, jpg, .dng,. .png, .tiff or .tiff would match (notice the omission of the .cr2).
And, since I really only use .cr2 files I should make the master: \.(cr2)$

These would not be matches:
IMG_5169-Trying this again.cr2 (because it is a .cr2 and there is no change in the file name that is preceded by a `(`)
IMG_5169.cr2 (because it does not possess the full name of the master)
IMG_5169-Trying this again(r).cr2 (because of the r)
IMG_5169.jpg (because it does not possess the full name of the master)
IMG_5169-Trying this again(s003_MJS).jpg (because of the s)

Sorry once again for any confusion I may have caused.

[Mario]

Mario, the rule does not make a Master a version of itself.  I did extensive testing and IMG_899.cr2 will never be a version of IMG_899.cr2, unless your testing algorithym is malfunctioning. 

I just made a general comment about too complex regexp and version rules.
After seeing your super-complex regexp I phased out since I'm no regexp expert.