Photo Ninja Buddy File definitions

[Ferdinand]

[Note:  successful settings are in reply #3]

Photo Ninja creates a couple of buddy files in a subfolder.  If the RAW file is {name}.{ext}, then the buddy files are {name}_{ext}.preview and {name}_{ext}.shadow_xmp

I'm hoping to create a single buddy file definition to cover this, rather than one definition for each RAW format.  I have these settings in the buddy file definition:
Master Expression:      \.(nef|nrw|arw|raf|cr2|crw|pef)$
Link Expression:          ^(_*{name}_{ext})\.(preview|shadow_xmp)$

Now this won't work because {ext} will return a period ".", like ".nef".   I can't see any easy way to get rid of it.  I already have a replacement expression ^_*// - is it possible to have two replacement expressions, so that one removes the _ at the start and the other removes the . towards the end?

At the moment the only option I can see is to create a buddy file definition for each RAW format, and have, for example:
Link Expression:          ^(_*{name}_nef)\.(preview|shadow_xmp)$

Is there another way?

[Mario]

The naming schemes third party vendors come up with never ceases to amaze me. It seems that they do that on purpose to make life hard for their users.

name_ext.preview ? Honestly...

There is surely a regular expression which can deal with that. Will need some tinkering, though. I'm currently in no position to spend time with this, so I hope others will give this a try.

[Ferdinand]

Well, you have complained in the past about vendors who used two periods and also used things like name.bib.xmp.  At least this formulation avoids those complications.

OK, I found the bit in the help file about multiple replacement expressions, so my question is, why doesn't this work:?
Master Expression:      \.(nef|nrw|arw|raf|cr2|crw|pef)$
Replacement Expr:      /^_*//\./_/
Link Expression:          ^(_*{filename})\.(preview|shadow_xmp)$

It looks to me like the replacement works on {name} and not {filename}?

[Ferdinand]

Success!!! 

The problem was an extra "/" at the start of the replacement expression:
So the working definition is
Master Expression:      \.(nef|nrw|arw|raf|cr2|crw|pef)$
Replacement Expr:      ^_*//\./_/
Link Expression:          ^(_*{filename})\.(preview|shadow_xmp)$

This of course assumes that you only have a single period in the file name.

[herman]

Good for you that you found it!
When I read your message I recalled an old post of mine regarding file relation definitions which addressed PN as well.
It took me longer to dig up that post than it took you to find a working definition.
Probably because I was preparing lunch at the same time 
Anyway, for what it is worth, this is what I had to share almost a year ago.
I have retired PN in the meantime, so things may have changed a little bit.....

[Ferdinand]

Interesting, Herman.  I'm surprised that that buddy file definition worked for PN, unless Picturecode have changed the syntax since then.  Filename will have name.ext and you need to change the "." to a "_".  There's also the shadow_xmp buddy file as well, if you use that option.

But your approach to buddy files is interesting.  Rather than writing a definition for each parent file type, which is how the defaults come configured, you write a definition for each buddy type.  I wonder if that's simpler and more elegant.

[herman]

I'm surprised that that buddy file definition worked for PN, unless Picturecode have changed the syntax since then.  Filename will have name.ext and you need to change the "." to a "_".  There's also the shadow_xmp buddy file as well, if you use that option.

Now I look at it again I am surprised as well 
I have uninstalled PN from my machines and removed the subfolders containing the buddy files, so there is no way for me to verify it right now.
But when you say that the dot in the filename is replaced by an underscore I can't see how my expression could have worked.
I did not use the shadow option, I am pretty sure of that.
Anyway, I edited the ref. post to show a link to your definition, so that future readers may get it right.
Thank you for pointing this out!

But your approach to buddy files is interesting.  Rather than writing a definition for each parent file type, which is how the defaults come configured, you write a definition for each buddy type.  I wonder if that's simpler and more elegant.

I use a definition for each file type my cameras generate (jpg, crw, cr2, dng, avi/mov).
I added separate definitions for the raw converters as I found that easier to understand and to maintain.
E.g. when DxO decides to change their buddy file naming I have to edit one rule in stead of multiple rules.
Moreover the raw converter definitions link to {filename}, whereas the other buddy file definitions link to {name}.

[Ferdinand]

I have moved this into tips and tricks, since that seems to be more appropriate.

I recall that Mario put in a lot of special code to allow the Bibble / Aftershot file.nef.xmp sidecars.  I wonder if this could have been avoided with your approach, using {filename}\.xmp.

One useful additional tip is to always check your buddy file relation definitions.  Whether or not versioning is working is more immediately obvious, but not so buddy files.  One  should use the "Test expressions ...." to check.  One should also use the buddy file script that ships with IMatch to list buddy files for a given file in the DB.  I found that the script was very useful for complex buddy file definitions, esp the one for Capture One 7.  The script shows whether the definition is actually working.